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. Im Mailserver-Check fällt ein Record durch, den ein sendender MTA verwenden könnte (Usage 2 oder 3) und der nicht DNSSEC-authentifiziert ist; Records, die für SMTP ohnehin unbrauchbar sind – Usage 0/1 oder ein Selector, Matching-Typ bzw. eine Digest-Länge, die kein Client nutzen kann –, werden wie eine Domain ganz ohne TLSA-Record bewertet. Folgenlos sind sie deshalb nicht: In einer DNSSEC-signierten Zone verpflichtet RFC 7672 §2.2.3 sendende MTAs weiterhin auf STARTTLS, eine Klartext-Zustellung über diesen Host ist also ausgeschlossen – die Authentifizierung nicht. Solche Records besser durch Usage 3 (DANE-EE) oder 2 (DANE-TA) ersetzen als einfach zu löschen.

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 den Record für den neuen Schlüssel zusätzlich zum alten und lassen beide mindestens zwei TTLs der TLSA-RRset stehen, bevor das neue Zertifikat live geht. RFC 7671 §8.1 beschreibt genau diesen Ablauf: die Records für die künftigen Schlüssel kommen „mindestens zwei Times to Live (TTLs) oder länger, bevor die neue Kette in Betrieb geht“ hinzu, damit die alte RRset aus den Caches der Absender altern kann. Den alten Record erst danach entfernen — ein Absender mit der alten RRset im Cache findet keine Übereinstimmung, und RFC 7672 §3.2 untersagt dann die Zustellung („Nachrichten DÜRFEN NICHT über den SMTP-Server zugestellt werden, wenn die Authentifizierung fehlschlägt“).

Hostname

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.

Zertifikat (PEM)

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.

Zu pinnendes Zertifikat

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).

Usage

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).

Selector

Matching-Type

Port

Für den Record selbst funktioniert jeder Port. Der Live-Zertifikatsabruf funktioniert nur auf 25, 443, 465, 587, 853, 990, 993 und 995 — für jeden anderen Port bitte das Zertifikat unten einfügen.

Protokoll

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.

Records werden in Ihrem Browser erzeugt; „Aktuellen Record & Zertifikat laden“ lässt unseren Server das DNS abfragen und eine TLS-Verbindung zum Zertifikat öffnen. Record Studio · Ergebnis mit dem Domain-Sicherheitscheck prüfen