13 von 13 angezeigt
Das erste Feld eines TLSA-Eintrags.
| Wert | Akronym | Beschreibung | Quellen |
|---|---|---|---|
0Anmerkung | PKIX-TA | PKIX-TA (0) ist die TLSA-Zertifikatsverwendung „CA constraint“. | RFC 6698 |
1 | PKIX-EE | PKIX-EE (1) ist die TLSA-Zertifikatsverwendung „Service certificate constraint“. | RFC 6698 |
2Anmerkung | DANE-TA | DANE-TA (2) ist die TLSA-Zertifikatsverwendung „Trust anchor assertion“. | RFC 6698 |
3Anmerkung | DANE-EE | DANE-EE (3) ist die TLSA-Zertifikatsverwendung „Domain-issued certificate“. | RFC 6698 |
255 | PrivCert | PrivCert (255) ist die TLSA-Zertifikatsverwendung „Reserved for Private Use“. | RFC 6698 |
| Bereich | Status | Beschreibung |
|---|---|---|
| 4–254 | unassigned | Unassigned |
Quelle: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), abgerufen am 2026-10-20. Datenlizenz: CC0-1.0. TLSA Certificate Usages
PKIX-TA (0) verlangt eine Kette zu einer öffentlichen CA, die zum TLSA-Eintrag passen muss; RFC 7672 rät für SMTP davon ab.
Die Zertifikatsverwendungen 0 und 1 ergänzen die gewöhnliche Validierung über die Web-PKI um eine Bedingung im DNS. Für SMTP zwischen Mailservern sollen TLSA-Einträge sie laut RFC 7672 §3.1.3 nicht verwenden (SHOULD NOT): Wer DNS fälschen kann, kann sie ohnehin ersetzen, und Mailserver haben keine gemeinsame Liste vertrauenswürdiger CAs.
DANE-TA (2) pinnt einen Vertrauensanker – meist die ausstellende CA – im DNS.
Bei der Zertifikatsverwendung 2 muss die Kette des Servers zu dem Zertifikat oder Schlüssel im TLSA-Eintrag führen; dieser Vertrauensanker muss keine öffentliche CA sein. RFC 7672 §3.1.2 verlangt, dass der Server den Vertrauensanker in seiner Kette mitsendet, wenn der Eintrag auf einen Schlüssel statt auf ein vollständiges Zertifikat passt.
DANE-EE (3) pinnt das eigene Zertifikat oder den eigenen Schlüssel des Servers im DNS; Namen und Ablaufdatum im Zertifikat werden nicht geprüft.
Bei der Zertifikatsverwendung 3 bindet allein der TLSA-Eintrag den Schlüssel an den Namen: Laut RFC 7672 §3.1.1 gilt der Server als authentifiziert, auch wenn kein Name im Zertifikat passt, und das Ablaufdatum des Zertifikats muss ignoriert werden (MUST). Der gängige Eintrag „3 1 1“ (DANE-EE, SPKI, SHA-256) übersteht Erneuerungen des Zertifikats, solange der Schlüssel derselbe bleibt.
Das zweite Feld eines TLSA-Eintrags.
| Wert | Akronym | Beschreibung | Quellen |
|---|---|---|---|
0 | Cert | Cert (0) ist der TLSA-Selektor „Full certificate“. | RFC 6698 |
1 | SPKI | SPKI (1) ist der TLSA-Selektor „SubjectPublicKeyInfo“. | RFC 6698 |
2 | C509 | C509 (2) ist der TLSA-Selektor „C509Certificate“. | RFC-ietf-cose-cbor-encoded-cert-21 |
255 | PrivSel | PrivSel (255) ist der TLSA-Selektor „Reserved for Private Use“. | RFC 6698 |
| Bereich | Status | Beschreibung |
|---|---|---|
| 3–254 | unassigned | Unassigned |
Quelle: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), abgerufen am 2026-10-20. Datenlizenz: CC0-1.0. TLSA Selectors
Das dritte Feld eines TLSA-Eintrags.
| Wert | Akronym | Beschreibung | Quellen |
|---|---|---|---|
0 | Full | Full (0) ist der TLSA-Abgleichstyp „No hash used“. | RFC 6698 |
1 | SHA2-256 | SHA2-256 (1) ist der TLSA-Abgleichstyp „256 bit hash by SHA2“. | RFC 6234 |
2 | SHA2-512 | SHA2-512 (2) ist der TLSA-Abgleichstyp „512 bit hash by SHA2“. | RFC 6234 |
255 | PrivMatch | PrivMatch (255) ist der TLSA-Abgleichstyp „Reserved for Private Use“. | RFC 6698 |
| Bereich | Status | Beschreibung |
|---|---|---|
| 3–254 | unassigned | Unassigned |
Quelle: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), abgerufen am 2026-10-20. Datenlizenz: CC0-1.0. TLSA Matching Types