TLSA-Record

Last change on 2025-10-07 • Created on 2025-10-07 • ID: NE-494A3

Verwendung

Ein TLSA-Record verweist einen Service auf Sicherheitsdetails (z.B. den Public Key eines Zertifikats), um das Server-Zertifikat in einem TLS-Handshake zu verifizieren.

Beispiel für Mailserver:

Typ Name (verwenden Sie @ für root) Usage Selector Matching Target TTL
A mail 198.51.100.1
MX @ mail.example.com.
TLSA _25._tcp.mail Domain-Issued Certificate Subject Public Key Info SHA-256 A9A70E866BC9A...

Beispiel für Weberver:

Typ Name (verwenden Sie @ für root) Usage Selector Matching Target TTL
A @ 203.0.113.1
TLSA _443._tcp Trust Anchor Assertion Subject Public Key Info SHA-256 0DEFB3A9C4D8E...
TLSA _443._tcp Domain-Issued Certificate Subject Public Key Info SHA-256 6B3D5F9E1A2C4...

Beschreibung

Der Client muss DANE unterstützen. Wenn ein Client DANE nicht unterstützt, prüft dieser nicht of ein TLSA-Record verfügbar ist.

TLSA-Records bilden einen zentralen Bestandteil von DANE (DNS-based Authentication of Named Entities). Wenn ein Client eine sichere Verbindung mit einem Server herstellt, wird ein TLS-Handshake durchgeführt. Während dieses Handshakes sendet der Server dem Client eine Zertifikatskette, die das Zertifikat vom Server selbst und alle Zertifikate von intermediate CAs enthält. Um die Echtheit des Server-Zertifikats zu verifizieren, vergleicht der Client die Zertifikatkette, die er vom Server erhalten hat, mit dem TLSA-Record, die er in der DNS-Antwort erhalten hat.

TLSA-Records sehen auf den ersten Blick etwas komisch aus, da sie zwischen manchen Informationen Unterstriche _ und Punkte . enthalten.

Namensschema:

Beispiele:
_<port-number>._<protocol>.<domain>

_443._tcp.www.example.com
_25._tcp.mail.example.com

CA-basierte Verifizierung und DANE im Vergleich:

  • Bei CA-basierter Verifizierung prüft der Client, ob das Server-Zertifikat tatsächlich von dem ausstellenden CA signiert wurde und ob diese CA vertrauenswürdig ist (Chain-Of-Trust). Um das prüfen zu können, besitzt der Client meist eine lokale Liste mit den Public Keys bekannter root-CAs. Dadurch ist sichergestellt, dass der Public Key des root-CA, der für die Überprüfung verwendet wird, vertrauenswürdig ist.

  • Bei DANE prüft der Client, ob die Zertifikatskette, die im TLSA-Record definierten Voraussetzungen erfüllt. Um das zu prüfen, muss der Client dem TLSA-Record vertrauen können. Der Client muss also garantieren können, das der TLSA-Record authentisch ist und nicht von Dritten manipuliert wurde. Um die Echtheit des TLSA-Records gewährleisten zu können, wird DANE in Kombination mit DNSSEC verwendet.

ℹ   Hinweis zur Sicherheit
Ein TLSA-Record kann ein Server-Zertifikat nur dann zuverlässig verifizieren, wenn der Client dem TLSA-Record selbst vertrauen kann. Dieses Vertrauen wird durch DNSSEC hergestellt. Ohne DNSSEC sind die Integrität und Authentizität des TLSA-Records nicht gewährleistet, was die DANE-Validierung unzuverlässig macht.

Beispiel: Wenn ein Angreifer über einen Man-in-the-Middle-Angriff sowohl das Zertifikat als auch den TLSA-Record austauscht, stimmen diese zwar weiterhin überein — sind aber nicht echt. Mit DNSSEC ist hingegen sichergestellt, dass der TLSA-Record nicht manipuliert wurde. Wenn das Zertifikat in diesem Szenario die Anforderungen des TLSA erfüllt, kann man dem Zertifikat ebenfalls vertrauen.

Eine Erklärung, was DNSSEC ist und wie es funktioniert, finden Sie in dem Artikel "Technische Konzepte » Architektur"

Verfügbare Optionen

Usage:

Erfordert zusätzlich CA-basierte Verifizierung Beschreibung
CA Constraint Ja Das Zertifikat oder der Public Key gehört einem öffentlichen CA im Chain-Of-Trust.
Service Certificate Constraint Ja Das Zertifikat oder der Public Key gehört dem Server (End Entity).
Trust Anchor Assertion Nein Das Zertifikat oder der Public Key gehört einem privaten root CA (Trust Anchor).
Domain-Issued Certificate Nein Das Zertifikat oder der Public Key gehört dem Server (End Entity).

Selector:

Beschreibung
Full Certificate Daten basieren auf dem gesamten Zertifikat
Subject Public Key Info Daten basieren auf dem Public Key

Matching:

Beschreibung
Full Original Zertifikat oder Public Key, kein Hash
SHA-256 SHA-256 Hash vom Zertifikat oder Public Key
SHA-512 SHA-512 Hash vom Zertifikat oder Public Key

Zonendatei

Die Werte für "Usage", "Selector" und "Matching" werden über Zahlen dargestellt.

Zum Beispiel:

_443._tcp    IN    TLSA    3 1 1                1306c288896771534a5b60744a535e1025f79b0b64e1bbc89278ba4d413cb9f1
                           | | └ Matching
                           | └── Selector
                           └──── CA Constraint

Die Zahlen stehen jeweils für folgende Werte:

Usage Selector Matching
0 CA Constraint 0 Full Certificate 0 Exact Match
1 Service Certificate Constraint 1 Subject Public Key Info 1 SHA-256 Hash
2 Trust Anchor Assertion 2 SHA-512 Hash
3 Domain-Issued Certificate
Table of Contents