← Record Studio

TLSA

TLSA-Records (RFC 6698, RFC 7671/7672) verankern ein Zertifikat oder dessen öffentlichen Schlüssel im DNS, damit TLS-Clients einen Server unabhängig von Zertifizierungsstellen prüfen können (DANE). Fügen Sie ein Zertifikat ein – dieser Generator berechnet den Digest lokal in Ihrem Browser.

DNSSEC ist Voraussetzung. DANE funktioniert nur in DNSSEC-signierten Zonen – ohne Validierung können Clients dem TLSA-Record nicht vertrauen, und dieser Sicherheitscheck bewertet einen TLSA-Record ohne DNSSEC als Fehlschlag.
Für SMTP lautet der Record-Name _25._tcp.<MX-Hostname> – der Host ist der MX-Hostname (z. B. mx1.example.net), nicht die Mail-Domain. Für einen Schlüsselwechsel veröffentlichen Sie vor dem Umstieg einen zweiten Record mit dem neuen Schlüssel zusätzlich zum alten (RFC 7671 §8.1).

Der Hostname des Servers für den gewählten Port — z. B. www.example.com für HTTPS, mx1.example.com für SMTP, dns.example.com für DNS over TLS.

Server-Zertifikat oder komplette Kette einfügen; für DANE-TA (Usage 2) wird der zweite Block – der Aussteller – verwendet. Oder oben Aktuellen Record & Zertifikat laden klicken, um es vom Server auszulesen.

Nach dem Abruf wählen, auf welches Zertifikat der gesendeten Kette der Record passt — Leaf = DANE-EE (Usage 3), eine CA = DANE-TA (Usage 2). Die Usage folgt Ihrer Auswahl. Für DANE-TA ein Intermediate pinnen: Server senden Intermediates, aber meist nicht die Root, und DANE-TA verlangt das gepinnte Zertifikat in der gesendeten Kette (RFC 7671 §5.2). Zum Pinnen der Root PKIX-TA (0) verwenden — validiert über den Client-Truststore — wobei PKIX-Usages für SMTP abgeraten werden (RFC 7672).

Zwei unabhängige Entscheidungen. PKIX (0/1) verlangt weiterhin, dass das Zertifikat gegen eine öffentliche CA validiert — TLSA ist nur ein zusätzlicher Pin. DANE (2/3) ersetzt die öffentliche CA: Der DNSSEC-signierte Record ist der Trust-Anchor, damit funktioniert auch ein privates oder selbstsigniertes Zertifikat. TA (0/2) pinnt die ausstellende CA, Leaf-Zertifikate lassen sich frei erneuern; EE (1/3) pinnt das Zertifikat selbst. Für SMTP empfiehlt RFC 7672 DANE-EE (3) oder DANE-TA (2).

Das Transport-Label im Record-Namen (_port._proto), RFC 6698 §3. Fast immer tcp. Der Live-Zertifikat-Abruf funktioniert nur über tcp — für udp/sctp das Zertifikat einfügen, um den Record zu bauen.

Läuft vollständig in Ihrem Browser. Record Studio · Ergebnis mit dem Domain-Sicherheitscheck prüfen