DANE/TLSA mit Postfix, Bind und Let's Encrypt konfigurieren

Q: Wie generiere ich einen TLSA-Eintrag für Let's Encrypt?

Verwende den Befehl openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | xxd -p -c 64 , um den SPKI-SHA-256-Hash zu extrahieren. Das 64 Zeichen lange Hexadezimal-Ergebnis bildet die Daten des TLSA mit den Parametern 3 1 1 .

Q: Muss ich den TLSA bei jeder Let's Encrypt-Erneuerung aktualisieren?

Nein, wenn du --reuse-key mit Certbot und die Kombination DANE-EE/SPKI ( 3 1 1 ) verwendest. Der SPKI-Hash hängt vom öffentlichen Schlüssel ab, nicht vom Zertifikat. Solange der private Schlüssel gleich bleibt, ändert sich der Hash nicht. Richte sicherheitshalber einen Verifizierungs-Deploy-Hook ein.

Q: Wie aktiviere ich die DANE-Verifizierung in Postfix?

Füge smtp_dns_support_level = dnssec und smtp_tls_security_level = dane in /etc/postfix/main.cf hinzu. Postfix verifiziert dann automatisch die TLSA-Einträge der Empfänger-Domains über DNSSEC. Wenn der TLSA fehlt oder ungültig ist, fällt Postfix auf opportunistisches TLS zurück.

Q: Wie teste ich, ob DANE korrekt konfiguriert ist?

Drei Verifizierungsebenen: 1) dig +dnssec _25._tcp.mail.captaindns.com TLSA für das DNS, 2) openssl s_client -connect mail.captaindns.com:25 -starttls smtp -dane_tlsa_domain für die Übereinstimmung Zertifikat/TLSA, 3) der DANE/TLSA-Inspektor von CaptainDNS für einen vollständigen Bericht inklusive DNSSEC-Kette.

Von CaptainDNS
Veröffentlicht am 22. Februar 2026

Architekturschema mit Postfix, Bind9 und Let's Encrypt, verbunden durch DANE/TLSA

TL;DR

DANE/TLSA verknüpft das TLS-Zertifikat deines Mailservers mit einem DNSSEC-signierten DNS-Eintrag und eliminiert die Abhängigkeit von Zertifizierungsstellen
Die empfohlene Kombination ist 3 1 1 (DANE-EE, SPKI, SHA-256): der TLSA-Hash überlebt Let's Encrypt-Erneuerungen, solange der private Schlüssel unverändert bleibt
Postfix unterstützt die ausgehende DANE-Verifizierung nativ mit smtp_dns_support_level = dnssec und smtp_tls_security_level = dane
Die Automatisierung erfolgt über einen Certbot-Deploy-Hook, der den TLSA-Hash neu generiert und die Bind9-Zone bei jeder Erneuerung neu lädt
Überprüfe dein Deployment mit dig TLSA, openssl s_client und dem DANE/TLSA-Inspektor von CaptainDNS

Du betreibst einen Postfix-Mailserver und möchtest deine SMTP-Verbindungen gegen Downgrade- und Man-in-the-Middle-Angriffe absichern? DANE (DNS-based Authentication of Named Entities) ist die Antwort. Indem du einen TLSA-Eintrag in deiner DNSSEC-signierten DNS-Zone veröffentlichst, teilst du entfernten Servern mit, welches TLS-Zertifikat dein Server vorlegen muss. Kein Mittelsmann, keine Zertifizierungsstelle, der du vertrauen musst.

Die Herausforderung bei Let's Encrypt ist die automatische Erneuerung alle 90 Tage. Wenn der TLSA-Hash nicht mehr zum Zertifikat passt, werden Server, die DANE verifizieren, die Verbindung ablehnen. Dieses Tutorial deckt die vollständige Konfiguration des Stacks Postfix + Bind9 + Let's Encrypt + DANE ab, einschließlich der Automatisierung der Erneuerung, um jede Unterbrechung zu vermeiden.

Dieser Leitfaden richtet sich an Linux-Systemadministratoren, die einen selbst gehosteten Mailserver betreiben. Er setzt Grundkenntnisse in Postfix, DNS und der Kommandozeile voraus. Für die Grundlagen von DANE und TLSA lies unsere Komplettanleitung zu DANE/TLSA (erster Artikel dieser Serie).

Voraussetzungen

Bevor du beginnst, stelle sicher, dass du über Folgendes verfügst:

Komponente	Mindestversion	Überprüfung
Debian/Ubuntu	12+ / 22.04+	`cat /etc/os-release`
Postfix	3.4+ (native DANE-Unterstützung)	`postconf mail_version`
Bind9	9.18+ (DNSSEC inline-signing)	`named -v`
Certbot	2.0+	`certbot --version`
DNSSEC aktiv	Zone signiert + DS beim Registrar	`dig +dnssec captaindns.com SOA`

Wenn DNSSEC auf deiner Zone noch nicht aktiv ist, ist das die Voraussetzung. Bind9 9.18+ unterstützt inline-signing, was die Verwaltung vereinfacht. Aktiviere es, bevor du fortfährst.

Ports und Netzwerkzugang

Postfix verwendet Port 25 (SMTP) und optional 587 (Submission). Let's Encrypt benötigt Port 80 oder 443 für die HTTP-01-Challenge (oder eine DNS-01-Challenge, wenn Port 80 auf dem Mailserver nicht verfügbar ist). Stelle sicher, dass diese Ports in deiner Firewall geöffnet sind.

Architektur des Stacks Postfix, Bind9 und Let's Encrypt mit DANE/TLSA

DNSSEC mit Bind9 konfigurieren

Wenn deine Zone bereits per DNSSEC signiert ist, springe zum nächsten Abschnitt. Andernfalls findest du hier die minimale Konfiguration mit Bind9 und inline-signing.

Inline-signing aktivieren

In deiner Zonenkonfigurationsdatei (/etc/bind/named.conf.local oder Äquivalent):

zone "captaindns.com" {
    type primary;
    file "/var/lib/bind/captaindns.com.zone";
    dnssec-policy default;
    inline-signing yes;
    key-directory "/var/lib/bind/keys";
};

Die Direktive dnssec-policy default generiert und verwaltet automatisch die ZSK- und KSK-Schlüssel. inline-signing signiert die Zone im laufenden Betrieb, ohne die Quelldatei zu verändern.

DS beim Registrar veröffentlichen

Nach dem ersten Laden der Zone generiert Bind9 die Schlüssel. Extrahiere den DS-Record:

# Generierte Schlüssel auflisten
ls /var/lib/bind/keys/

# DS-Record extrahieren (Dateinamen des KSK anpassen)
dnssec-dsfromkey /var/lib/bind/keys/Kcaptaindns.com.+013+xxxxx.key

Übermittle den DS-Record an deinen Registrar (Weboberfläche oder API). Die Propagation dauert je nach Registrar wenige Minuten bis 48 Stunden.

DNSSEC-Kette überprüfen

dig +dnssec +short captaindns.com SOA
# Muss den SOA mit dem Flag "ad" (Authenticated Data) zurückgeben

dig +dnssec captaindns.com DNSKEY
# Muss die DNSKEY mit den RRSIG-Signaturen zurückgeben

Let's Encrypt-Zertifikat generieren

Zertifikat anfordern

# Certbot installieren (falls noch nicht installiert)
apt install certbot

# Zertifikat für den Hostnamen des Mailservers anfordern
certbot certonly --standalone -d mail.captaindns.com

Wenn Port 80 bereits von einem anderen Dienst belegt ist, verwende das Webroot-Plugin oder die DNS-01-Challenge:

# Alternative mit Webroot (wenn Apache/Nginx auf dem Server läuft)
certbot certonly --webroot -w /var/www/html -d mail.captaindns.com

# Alternative mit DNS-Challenge (wenn Port 80 nicht verfügbar)
certbot certonly --manual --preferred-challenges dns -d mail.captaindns.com

Postfix für die Verwendung des Zertifikats konfigurieren

Bearbeite /etc/postfix/main.cf:

# TLS-Zertifikat (Empfang - smtpd)
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Ausgehende DANE-Verifizierung (smtp)
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_loglevel = 1

Die beiden Blöcke dienen unterschiedlichen Zwecken: smtpd_tls_* konfiguriert TLS für eingehende Verbindungen (dein Server präsentiert sein Zertifikat), während smtp_tls_* TLS für ausgehende Verbindungen konfiguriert (Postfix verifiziert den TLSA des Empfängers).

Postfix neu laden:

postfix reload

TLSA-Eintrag erstellen

TLSA-Parameter wählen

Die von RFC 7672 für SMTP empfohlene Kombination ist 3 1 1:

Feld	Wert	Bedeutung
Usage	3 (DANE-EE)	Direkte Verifizierung des Serverzertifikats
Selector	1 (SPKI)	Hash des öffentlichen Schlüssels (nicht des gesamten Zertifikats)
Matching type	1 (SHA-256)	SHA-256-Hash

Der Vorteil des SPKI-Selectors (1): Der Hash ändert sich nicht, wenn du das Let's Encrypt-Zertifikat erneuerst, solange der private Schlüssel gleich bleibt. Das ist entscheidend, um den TLSA nicht bei jeder Erneuerung aktualisieren zu müssen.

TLSA-Hash generieren

# SPKI-SHA-256-Hash aus dem Zertifikat extrahieren
openssl x509 -in /etc/letsencrypt/live/mail.captaindns.com/cert.pem \
  -pubkey -noout | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 64

Das Ergebnis ist ein 64 Zeichen langer Hexadezimal-String, zum Beispiel:

a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890

Du kannst auch den DANE/TLSA-Generator von CaptainDNS verwenden, um den Eintrag ohne Befehlszeile zu generieren.

TLSA in die Bind9-Zone eintragen

Der Name des TLSA-Eintrags folgt dem Format _port._protocol.hostname. Für Port 25 (SMTP):

_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890

Füge diese Zeile in deine Zonendatei ein, erhöhe die SOA-Seriennummer und lade neu:

# Zone neu laden (Bind9 signiert automatisch mit inline-signing)
rndc reload captaindns.com

Veröffentlichung überprüfen

# Überprüfen, dass der TLSA veröffentlicht und signiert ist
dig +dnssec _25._tcp.mail.captaindns.com TLSA

# Erwartetes Ergebnis: der TLSA mit den RRSIG

Erneuerung automatisieren

Das ist der kritische Teil. Let's Encrypt erneuert das Zertifikat alle 90 Tage. Wenn du DANE-EE mit SPKI (3 1 1) verwendest, ändert sich der Hash nicht, solange Certbot denselben privaten Schlüssel wiederverwendet. Aber du musst das sicherstellen und den Fall vorsehen, dass der Schlüssel sich ändert.

Strategie zur Schlüsselbeibehaltung

Standardmäßig generiert Certbot bei jeder Erneuerung einen neuen Schlüssel. Um denselben Schlüssel beizubehalten (und damit denselben TLSA-Hash), füge die Option --reuse-key hinzu:

# Wiederverwendung des privaten Schlüssels erzwingen
certbot certonly --standalone -d mail.captaindns.com --reuse-key

Oder füge in /etc/letsencrypt/renewal/mail.captaindns.com.conf hinzu:

[renewalparams]
reuse_key = True

Deploy-Hook für automatische Aktualisierung

Auch mit --reuse-key ist es ratsam, einen Deploy-Hook einzurichten, der den Hash überprüft und den TLSA bei Bedarf aktualisiert. Erstelle das Skript /etc/letsencrypt/renewal-hooks/deploy/update-tlsa.sh:

#!/bin/bash
# Certbot-Deploy-Hook: TLSA aktualisieren, wenn sich der SPKI-Hash ändert

DOMAIN="mail.captaindns.com"
ZONE="captaindns.com"
ZONE_FILE="/var/lib/bind/captaindns.com.zone"
CERT="/etc/letsencrypt/live/$DOMAIN/cert.pem"

# Neuen SPKI-SHA-256-Hash berechnen
NEW_HASH=$(openssl x509 -in "$CERT" -pubkey -noout | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 64)

# Aktuellen Hash aus dem DNS abrufen
CURRENT_HASH=$(dig +short _25._tcp.$DOMAIN TLSA | awk '{print $4}')

if [ "$NEW_HASH" != "$CURRENT_HASH" ]; then
  echo "TLSA hash changed, updating zone..."

  # Hash in der Zonendatei ersetzen
  sed -i "s/\(IN TLSA 3 1 1 \)[a-f0-9]\{64\}/\1$NEW_HASH/" "$ZONE_FILE"

  # Seriennummer erhöhen (Format YYYYMMDDNN)
  CURRENT_SERIAL=$(grep -oP '\d{10}' "$ZONE_FILE" | head -1)
  NEW_SERIAL=$((CURRENT_SERIAL + 1))
  sed -i "s/$CURRENT_SERIAL/$NEW_SERIAL/" "$ZONE_FILE"

  # Zone neu laden
  rndc reload "$ZONE"

  echo "TLSA updated: $NEW_HASH"
else
  echo "TLSA hash unchanged, no update needed."
fi

# Postfix neu laden, um das neue Zertifikat zu übernehmen
postfix reload

Das Skript ausführbar machen:

chmod +x /etc/letsencrypt/renewal-hooks/deploy/update-tlsa.sh

Erneuerung testen

# Erneuerung simulieren (Dry-Run)
certbot renew --dry-run

# Erneuerung erzwingen (um den Hook zu testen)
certbot renew --force-renewal

Ablauf der automatischen Erneuerung: Certbot erneuert das Zertifikat, der Deploy-Hook überprüft den SPKI-Hash und aktualisiert den TLSA in Bind9 bei Bedarf

SPKI-Rollover-Strategie (Schlüsselwechsel)

Wenn du den privaten Schlüssel neu generieren musst (Kompromittierung, Migration), veröffentliche den neuen TLSA vor dem Deployment des neuen Zertifikats. RFC 7671 empfiehlt eine Phase der doppelten Veröffentlichung:

Neuen Schlüssel generieren und seinen SPKI-Hash berechnen
Beide TLSA in der Zone veröffentlichen (alter + neuer)
DNS-Propagation abwarten (mindestens 2x TTL)
Neues Zertifikat deployen
Alten TLSA nach der Propagation entfernen

; Doppelter TLSA während der Übergangsphase
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <alter-hash>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <neuer-hash>

Konfiguration überprüfen

DNS-Verifizierung

# TLSA überprüfen
dig +short _25._tcp.mail.captaindns.com TLSA
# Erwartet: 3 1 1 <hash-64-zeichen>

# DNSSEC überprüfen
dig +dnssec _25._tcp.mail.captaindns.com TLSA | grep -c "RRSIG"
# Erwartet: >= 1

TLS-Verifizierung

# TLS-Verbindung mit TLSA-Verifizierung testen
openssl s_client -connect mail.captaindns.com:25 -starttls smtp \
  -dane_tlsa_domain mail.captaindns.com \
  -dane_tlsa_rrdata "3 1 1 $(dig +short _25._tcp.mail.captaindns.com TLSA | awk '{print $4}')"

Das Ergebnis muss Verification: OK und DANE TLSA 3 1 1 matched EE certificate anzeigen.

Ausgehende Postfix-Verifizierung

Überprüfe, dass Postfix DANE für ausgehende E-Mails korrekt verifiziert:

# Test-E-Mail senden und Logs überprüfen
echo "Test DANE" | mail -s "DANE test" test@gmail.com
grep "Verified TLS connection" /var/log/mail.log | tail -5

Die Logs müssen dane im Sicherheitslevel erwähnen.

Online-Verifizierung

Nutze den DANE/TLSA-Syntaxprüfer von CaptainDNS, um die Syntax deines Eintrags zu validieren, und dann den DANE/TLSA-Inspektor für eine vollständige Überprüfung inklusive der DNSSEC-Kette.

Empfohlener Aktionsplan

Vollständiges DANE-Deployment auf einem selbst gehosteten Mailserver in 6 Schritten

dnssec-policy default und inline-signing yes in der Bind9-Zone konfigurieren. Den DS-Record beim Registrar veröffentlichen. Die Vertrauenskette mit dig +dnssec überprüfen.
certbot certonly --standalone -d mail.captaindns.com --reuse-key ausführen, um das Zertifikat mit Schlüsselbeibehaltung zu erhalten.
main.cf mit den Zertifikatspfaden bearbeiten (smtpd_tls_*), die ausgehende DANE-Verifizierung aktivieren (smtp_dns_support_level = dnssec, smtp_tls_security_level = dane).
Den SPKI-SHA-256-Hash mit openssl generieren, den Eintrag _25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash> in die Zone eintragen, mit rndc reload neu laden.
Den Deploy-Hook /etc/letsencrypt/renewal-hooks/deploy/update-tlsa.sh erstellen, der die SPKI-Hashes vergleicht und den TLSA bei Bedarf aktualisiert. Mit certbot renew --force-renewal testen.
Mit dig TLSA, openssl s_client -dane_tlsa_domain, den Postfix-Logs und dem DANE/TLSA-Inspektor von CaptainDNS validieren.

FAQ

Wie generiere ich einen TLSA-Eintrag für Let's Encrypt?

Verwende den Befehl openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | xxd -p -c 64, um den SPKI-SHA-256-Hash zu extrahieren. Das 64 Zeichen lange Hexadezimal-Ergebnis bildet die Daten des TLSA mit den Parametern 3 1 1.

Muss ich den TLSA bei jeder Let's Encrypt-Erneuerung aktualisieren?

Nein, wenn du --reuse-key mit Certbot und die Kombination DANE-EE/SPKI (3 1 1) verwendest. Der SPKI-Hash hängt vom öffentlichen Schlüssel ab, nicht vom Zertifikat. Solange der private Schlüssel gleich bleibt, ändert sich der Hash nicht. Richte sicherheitshalber einen Verifizierungs-Deploy-Hook ein.

Wie aktiviere ich die DANE-Verifizierung in Postfix?

Füge smtp_dns_support_level = dnssec und smtp_tls_security_level = dane in /etc/postfix/main.cf hinzu. Postfix verifiziert dann automatisch die TLSA-Einträge der Empfänger-Domains über DNSSEC. Wenn der TLSA fehlt oder ungültig ist, fällt Postfix auf opportunistisches TLS zurück.

Funktioniert DANE mit selbstsignierten Zertifikaten?

Ja. Bei DANE-EE (Usage 3) wird das Zertifikat durch den TLSA im DNS validiert, nicht durch eine Zertifizierungsstelle. Ein selbstsigniertes Zertifikat mit einem korrekten TLSA und einer gültigen DNSSEC-Zone wird von Servern akzeptiert, die DANE verifizieren.

Wie teste ich, ob DANE korrekt konfiguriert ist?

Drei Verifizierungsebenen: 1) dig +dnssec _25._tcp.mail.captaindns.com TLSA für das DNS, 2) openssl s_client -connect mail.captaindns.com:25 -starttls smtp -dane_tlsa_domain für die Übereinstimmung Zertifikat/TLSA, 3) der DANE/TLSA-Inspektor von CaptainDNS für einen vollständigen Bericht inklusive DNSSEC-Kette.

Ist Bind zwingend erforderlich oder kann man einen anderen DNS-Server verwenden?

Bind9 ist nicht zwingend. Jeder DNS-Server mit DNSSEC-Unterstützung funktioniert: NSD, Knot DNS, PowerDNS. Die Prinzipien sind identisch, nur die Konfigurationssyntax unterscheidet sich. Bind9 wird in diesem Tutorial verwendet, weil es auf Linux-Servern am weitesten verbreitet ist und sein inline-signing die DNSSEC-Verwaltung vereinfacht.

Was passiert, wenn der TLSA nicht mehr zum Zertifikat passt?

Server, die DANE verifizieren (wie Postfix mit dane oder Gmail), werden die TLS-Verbindung ablehnen und je nach Richtlinie auf unverschlüsselt zurückfallen oder die Nachricht ablehnen. Deshalb ist die doppelte TLSA-Veröffentlichung bei Schlüsselrotationen essenziell. Wenn dein TLSA desynchronisiert ist, entferne ihn vorübergehend, um auf opportunistisches TLS zurückzufallen, bis das Problem behoben ist.

📚 Verwandte DANE/TLSA-Leitfäden

DANE/TLSA: die Komplettanleitung zur Authentifizierung von E-Mail-Zertifikaten per DNS: Funktionsweise, TLSA-Aufbau, empfohlene Einsatzgebiete und Vergleich mit MTA-STS
Fehlerbehebung bei DANE/TLSA: häufige Fehler diagnostizieren und beheben (demnächst)
DANE für Exchange oder Microsoft 365 deployen (demnächst)