DANE TLSA Generator

So verwenden Sie diesen DANE TLSA Generator

In vier Schritten von Ihrem PEM-Zertifikat zum veröffentlichungsfertigen DNS-Eintrag.

Schritt 1: TLSA-Parameter konfigurieren

Die richtige Parameterwahl entscheidet über Sicherheit und Wartungsaufwand. Für SMTP empfiehlt RFC 7672 diese Kombination:

Schritt 2: Zertifikat bereitstellen

Fügen Sie Ihr Zertifikat im PEM-Format ein:

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQON...
-----END CERTIFICATE-----

So erhalten Sie das Zertifikat:

# Vom Mailserver per STARTTLS
openssl s_client -connect mail.captaindns.com:25 -starttls smtp 2>/dev/null | openssl x509

# Aus einer Datei auf dem Server
cat /etc/letsencrypt/live/mail.captaindns.com/cert.pem

Schritt 3: Kopieren und veröffentlichen

Der Generator erzeugt einen veröffentlichungsfertigen Record:

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4

Schritt 4: Deployment überprüfen

Nutzen Sie unseren DANE TLSA Checker, um zu bestätigen, dass der Record online und korrekt DNSSEC-signiert ist.

Anleitung zu den TLSA-Parametern

Jeder Parameter beeinflusst Sicherheit und Wartungsaufwand Ihres DANE-Deployments. Hier die Details zu jeder Entscheidung.

Certificate Usage: welchen Typ wählen?

Für SMTP (RFC 7672) werden nur DANE-TA (2) und DANE-EE (3) verwendet. PKIX-TA (0) und PKIX-EE (1) sind in RFC 6698 definiert, gelten aber nicht für opportunistisches SMTP: MTAs verlassen sich auf DNSSEC, nicht auf die PKIX-Validierung.

Wählen Sie standardmäßig DANE-EE (3) mit dem Selector SPKI (1) und SHA-256-Matching (1). Das ist die einfachste und robusteste Option. DANE-TA (2) ist eine fortgeschrittene Wahl mit einer Ketten-Bedingung (siehe Deployment-Strategien).

Selector: Cert vs. SPKI

SPKI (1) wird empfohlen, um die Häufigkeit der DNS-Aktualisierungen zu reduzieren.

Matching Type: Full vs. Hash

SHA-256 (1) ist der Standard. Full (0) kann DNS-Antworten über 512 Bytes erzeugen und UDP-Trunkierungsprobleme verursachen. SHA-512 verdoppelt die Größe ohne messbaren Sicherheitsvorteil.

Wählen Sie Ihre Parameter im Generator oben und fügen Sie Ihr PEM-Zertifikat ein.

Voraussetzung: DNSSEC

DANE funktioniert nicht ohne DNSSEC. Ohne signierte DNS-Antworten ignoriert jeder MTA Ihre TLSA-Records. Prüfen Sie diese Voraussetzung vor der Veröffentlichung:

DNSSEC prüfen

1. Stellen Sie sicher, dass Ihr Registrar DNSSEC unterstützt
2. Aktivieren Sie die DNSSEC-Signierung bei Ihrem DNS-Hoster
3. Fügen Sie die DS-Records bei Ihrem Registrar hinzu
4. Warten Sie auf die Propagation (kann 24-48 Stunden dauern)

DNS-Anbieter mit DNSSEC

Deployment-Strategien

Ihr Zertifikats-Workflow bestimmt die richtige DANE-Strategie. Hier die drei gängigsten Szenarien.

Szenario 1: Let's Encrypt mit Schlüsselwiederverwendung

Konfiguration:

# Generierung mit Schlüsselwiederverwendung
certbot certonly --reuse-key -d mail.captaindns.com

# TLSA Record (ändert sich nicht zwischen Erneuerungen)
3 1 1 <sha256-spki>

Vorteil: Der TLSA-Record ändert sich nie, solange der Schlüssel wiederverwendet wird.

Szenario 2: Let's Encrypt mit DANE-TA (fortgeschrittene Option)

Bei DANE-TA (Usage 2) muss das gepinnte Zertifikat - oder ein von ihm signiertes Zertifikat - in der vom Server gesendeten TLS-Kette vorhanden sein (RFC 7671 Abschnitt 5). MTAs senden das Stammzertifikat in der Regel jedoch NICHT: Pinnen Sie das tatsächlich ausgelieferte Intermediate (zum Beispiel Let's Encrypt R10/R11), nicht die Wurzel ISRG Root X1.

Konfiguration:

# Das vom Server tatsächlich gesendete Intermediate pinnen (z. B. R10/R11)
2 1 1 <sha256-spki-des-intermediate>

Warnung: Wenn Sie eine Wurzel (ISRG Root X1) pinnen, konfigurieren Sie den Server so, dass er dieses Zertifikat in die TLS-Kette aufnimmt, sonst schlägt die DANE-TA-Validierung fehl. Im Zweifel bevorzugen Sie DANE-EE (3) + SPKI (1), das diese Ketten-Bedingung nicht hat.

Vorteil: Keine DNS-Aktualisierung nötig, solange das Intermediate in der Kette unverändert bleibt.

Szenario 3: Rotation mit doppeltem Record

Vor der Rotation:

_25._tcp.mail.captaindns.com.  TLSA  3 1 1 <hash-aktuelles-cert>
_25._tcp.mail.captaindns.com.  TLSA  3 1 1 <hash-zukünftiges-cert>

Nach der Rotation: Entfernen Sie den alten Hash. Warten Sie mindestens 2× TTL zwischen der Veröffentlichung des neuen Records und der Zertifikatsrotation.

DNS-Veröffentlichung nach Anbieter

Hier finden Sie die Schritt-für-Schritt-Anleitung für die drei häufigsten DNS-Anbieter.

Cloudflare

1. Gehen Sie zu den DNS-Einstellungen Ihrer Domain
2. Fügen Sie einen Eintrag hinzu:
   • Typ: TLSA
   • Name: _25._tcp.mail
   • Usage: 3
   • Selector: 1
   • Matching Type: 1
   • Certificate: Ihr SHA-256-Hash

AWS Route 53

1. Öffnen Sie die gehostete Zone
2. Erstellen Sie einen Eintrag:
   • Name: _25._tcp.mail.captaindns.com
   • Typ: TLSA
   • Wert: 3 1 1 <hash>
   • TTL: 3600

OVH / Generisches Format

1. Gehen Sie zur DNS-Zone
2. Fügen Sie einen Eintrag hinzu:
   • Subdomain: _25._tcp.mail
   • Typ: TLSA
   • Ziel: 3 1 1 <hash>
   • TTL: 3600

Best Practices und häufige Fehler

DANE ist strikt: Eine Fehlkonfiguration blockiert eingehende Mail. Vermeiden Sie diese klassischen Fehler.

• DNSSEC ist Pflicht: Ohne signierte und validierte Zone ignorieren Resolver den TLSA-Record und DANE ist völlig wirkungslos. Das ist der häufigste Fehler.
• Additive Rotation: Veröffentlichen Sie den NEUEN TLSA-Record ZUSÄTZLICH zum alten, warten Sie auf die DNS-Propagation und den Ablauf der TTL, und entfernen Sie den alten erst, nachdem das alte Zertifikat außer Betrieb genommen wurde. Löschen Sie den alten nie, bevor der neue propagiert ist.
• Publish-then-deploy: Veröffentlichen Sie den TLSA-Record und lassen Sie ihn propagieren, BEVOR Sie das Zertifikat auf dem Server umstellen, niemals umgekehrt.
• SPKI übersteht die Erneuerung: Mit dem Selector SPKI (1) bleibt der Record nach der Erneuerung gültig, solange derselbe Schlüssel wiederverwendet wird, was DNS-Aktualisierungen reduziert. Der Selector Cert (0) erzwingt eine erneute Veröffentlichung bei jeder Erneuerung.
• Übereinstimmung mit dem ausgelieferten Zertifikat: Der TLSA-Record muss mit dem tatsächlich vom MX präsentierten Zertifikat übereinstimmen. Eine Abweichung zwischen Hostname und Zertifikat führt zum Fehlschlag der Validierung.

Vollständige E-Mail-Sicherheit mit DANE

DANE allein reicht nicht. Für maximalen Schutz des E-Mail-Transports kombinieren Sie DANE mit MTA-STS und TLS-RPT:

1. DANE (Zertifikatsauthentifizierung über DNS)

Verifiziert die Identität des Empfängerservers über DNSSEC.

• Verwenden Sie diesen Generator
• DANE-Deployment überprüfen

2. MTA-STS (TLS-Durchsetzung über HTTPS)

Alternative zu DANE ohne DNSSEC.

• MTA-STS-Policy generieren
• MTA-STS prüfen

3. TLS-RPT (Fehler melden)

Meldet TLS-Verbindungsfehler (DANE und MTA-STS).

• TLS-RPT-Record generieren
• TLS-RPT prüfen

Empfohlene Deployment-Reihenfolge

Folgen Sie dieser Reihenfolge, jeder Schritt baut auf dem vorherigen auf:

1. DNSSEC auf der Domain aktivieren (Voraussetzung für DANE)
2. TLSA-Records veröffentlichen (mit diesem Generator erstellen)
3. TLS-RPT konfigurieren, um Fehlerberichte zu erhalten
4. MTA-STS als zusätzliche Schutzebene hinzufügen (optional, aber empfohlen)
5. TLS-RPT-Berichte regelmäßig überwachen und auf Fehler reagieren

FAQ - Häufig gestellte Fragen

F: Wie erstelle ich einen DANE-TLSA-Record?

A: Nutzen Sie unseren Generator: Wählen Sie den Usage-Typ (DANE-EE empfohlen), den Selector (SPKI für Stabilität), den Matching Type (SHA-256) und fügen Sie Ihr PEM-Zertifikat ein. Das Tool generiert den vollständigen, veröffentlichungsfertigen DNS-Eintrag.

F: Welchen Certificate Usage sollte ich für DANE wählen?

A: Für die meisten SMTP-Deployments wird DANE-EE (3) mit SPKI-Selector und SHA-256-Matching empfohlen. Für eine einfachere Zertifikatsrotation verwenden Sie DANE-TA (2) auf dem Intermediate, das Ihr Server tatsächlich ausliefert, nicht auf der Wurzel: RFC 7671 Abschnitt 5.2.2 verlangt, dass das gepinnte Zertifikat in der TLS-Kette enthalten ist.

F: Sollte ich das vollständige Zertifikat oder einen Hash verwenden?

A: Verwenden Sie immer einen SHA-256-Hash. Vollständige Daten (Matching Type 0) erzeugen sehr große DNS-Einträge mit Risiko der UDP-Trunkierung. SHA-256 erzeugt einen kompakten 64-Zeichen-String.

F: Was ist der SPKI-Selector?

A: Der SPKI-Selector (1) hasht nur den Public Key des Zertifikats. Der TLSA-Record bleibt gültig, wenn Sie mit demselben Schlüsselpaar erneuern, im Gegensatz zum Cert-Selector (0), der sich bei jeder Erneuerung ändert.

F: Wie stelle ich einen DANE-TLSA-Record bereit?

A: 1) Aktivieren Sie DNSSEC, 2) Fügen Sie den TLSA unter _25._tcp.ihrmailserver hinzu, 3) Warten Sie auf die DNS-Propagation, 4) Prüfen Sie mit unserem DANE TLSA Checker. Der Record muss DNSSEC-signiert sein.

F: Wie gehe ich mit Let's Encrypt-Erneuerungen bei DANE um?

A: Zwei Strategien: DANE-TA (Usage 2) auf dem tatsächlich ausgelieferten Let's Encrypt-Intermediate (R10 oder R11), nicht auf der Wurzel ISRG Root X1, die MTAs nicht in der TLS-Kette senden. Oder DANE-EE (Usage 3) mit SPKI-Selector und --reuse-key in Certbot.

Ergänzende Tools

Nützliche Ressourcen

• RFC 6698 - DANE TLSA (Originalspezifikation)
• RFC 7671 - Updates to DANE (betriebliche Aktualisierungen)
• RFC 7672 - SMTP Security via DANE (DANE für SMTP)
• Certbot - Reuse Key (Schlüsselwiederverwendung für DANE)
• Microsoft - DANE with DNSSEC (Exchange Online-Anleitung)