TLSA

TLSA | Transportverschlüsselung mit DANE

Peter Lange

31 Okt. 2025 — 4 min read

TLSA DANE

TLSA/DANE-Records für Mailserver sind ein wirkungsvolles Mittel, um die Transportverschlüsselung abzusichern, auch (und gerade) bei Wildcard-Zertifikaten.
Ich erkläre mit diesem Beitrag, wie du einen TLSA-Record für ein Wildcard-Zertifikat einrichtest (z. B. *.example.com).

Grundprinzip von TLSA/DANE

Ein TLSA-Record (port.protocol.hostname) verknüpft DNS mit dem verwendeten TLS-Zertifikat.

Für einen SMTP-Server auf Port 25 ist diese Form üblich:

25.tcp.mail.example.com.  IN  TLSA  3 1 1  <Hashwert>

Aufbau des TLSA Records

Für ein besseres Verständnis, erkläre ich kurz die einzelnen Elemente des TLSA Records

_25 → Port des TLS-Dienstes (SMTP)

tcp → das zu verwendende Protokoll

mail.example.com → Hostname, der im MX-Record steht

3 → Wie benutzt du diesen TLSA-Record / Usage (DANE-EE)

1 → Was soll verifiziert werden / Selector (SubjectPublicKeyInfo)

1 → Wie soll verglichen werden / Matching Type (SHA-256)

<Hashwert> → SHA-256-Fingerprint des Zertifikats oder Schlüssels

📌 Wichtig: DANE funktioniert nicht mit SNI-basierter Wildcard-Nutzung allein – der MX-Hostname muss dem Zertifikat entsprechen oder von der Wildcard abgedeckt sein.

Voraussetzungen prüfen

Damit du überhaupt in der lage bist, TLSA-Records nutzen zu können, bedarf es einger Vorraussetzungen.

Der MX-Record deiner Domain zeigt auf mail.example.com.
Dein Wildcard-Zertifikat deckt mail.example.com ab (z. B. *.example.com).
Du nutzt DNSSEC für die Domain (Pflicht für DANE).
Der Mailserver unterstützt TLS (z. B. Postfix mit smtpdtlssecuritylevel = dane).

TLSA-Fingerprint erzeugen

Du benötigst den SHA-256-Fingerprint des Public Keys (nicht des ganzen Zertifikats).
Wie du den Fingerprint deines Zertifikates erhälst, zeige ich dir anhand eines Beispiels mit OpenSSL:

Public Key extrahieren

openssl x509 -in mail.example.com.pem -noout -pubkey > pubkey.pem

SHA-256-Hash erzeugen

openssl pkey -pubin -in pubkey.pem -outform DER | openssl sha256

Die Ausgabe sieht dann etwa so aus:

(stdin)=  3F21C995B7C9F0B4E4E2CBA4B65E1C290F20D295C599C04D1897DB4B7D75E1A0

Dieser Hashwert kommt in deinen TLSA-Record an der Stelle von <Hashwert> .

📌 Alternative: Du kannst direkt den Zertifikatshash nehmen (selector=0), aber empfohlen ist der Public Key (selector=1), weil er beim Zertifikatserneuern stabil bleibt.

TLSA-Record erstellen

Jetzt zeige ich dir nachdem wir alles geklärt haben, den eigentlichen Vorgang zum erstellen eines TLSA-Records anhand des folgenden Beispiels:

TLSA-Record für einen SMTP Server mit dem DNS Namen mail.example.com auf Port 25

Anhand der oben beschriebenen Punkte, ergibt sich folgender zu setzender DNS Eintrag:

_25.tcp.mail.example.com. 3600 IN TLSA 3 1 1 3F21C995B7C9F0B4E4E2CBA4B65E1C290F20D295C599C04D1897DB4B7D75E1A0

3600 → TTL (selbstverständlich anpassbar, je nach Provider)

3 1 1 → Usage 3 (DANE-EE), Selector 1, Match SHA-256

👉 Wenn du auch Submission/SMTPS absichern willst:

_465.tcp.mail.example.com. IN TLSA 3 1 1 <Hash>
_587.tcp.mail.example.com. IN TLSA 3 1 1 <Hash>

👉 Wenn du auch einen Webservice absichern willst:

_443.tcp.www.example.com. IN TLSA 3 1 1 <Hash>
_8443.tcp.secureapp.example.com. IN TLSA 3 1 1 <Hash>

DNSSEC aktivieren & Record signieren

Ohne DNSSEC wird der TLSA-Record von anderen Mailservern ignoriert.
Stelle sicher, dass:

DNSSEC für deine Domain aktiv ist (z. B. beim Domain-Registrar oder in BIND).
Der TLSA-Record signiert und im DNS veröffentlicht ist.

Du kannst mit folgendem Befehl testen:

dig +dnssec _25._tcp.mail.example.com TLSA

und folgende Beispielantwort erhalten

;; ANSWER SECTION:
_25._tcp.mail.example.com. 3600   IN      TLSA    3 1 1 3F21C995B7C9F0B4E4E2CBA4B65E1C290F20D295C599C04D1897DB4B 7D75E1A0
_25._tcp.mail.example.com. 3600   IN      RRSIG   TLSA 13 5 300 20251101095959 20251030075959 34505 example.com. AFZB59N/6zwEh+7qjmAEAVM4A+5DAK/AG6gNHu9MqSXQGp9zD0t9t8A4 wTr0Ut0awkFakWGJij42ZD09kSwW2A==

oder mit hash-slinger:

tlsa --verify mail.example.com 25

Besonderheiten bei Wildcard-Zertifikaten

Wildcard *.example.com ist für mail.example.com gültig ✅
Aber nicht für die Root-Domain (example.com) ❌
Du musst für jeden MX-Hostname einen eigenen TLSA-Record anlegen
Wildcard-TLSA-Records funktionieren nicht.

Beispiel:

Wenn du auch mx2.example.com betreibst, brauchst du einen zweiten Eintrag:

_25._tcp.mx2.example.com. IN TLSA 3 1 1 <Hash>

(Entweder mit dem gleichen Wildcard-Zertifikat oder einem eigenen)

Optional: Automatisierung

Wenn du Zertifikate automatisch erneuerst (z. B. über Certbot), kannst du den TLSA-Hash in einem Hook-Script automatisch neu erzeugen und in DNS aktualisieren.

Beispiel-Hook:

#!/bin/bash

CERT="/etc/letsencrypt/live/mail.example.com/fullchain.pem"
HASH=$(openssl x509 -in $CERT -noout -pubkey | \
       openssl pkey -pubin -outform DER | \
       openssl sha256 | awk '{print $2}')

#DNS API call / nsupdate mit neuem HASH

echo "Neuer TLSA Hash: $HASH"