tls.cert.dane_ee_pinned

Zertifikat durch DANE-EE gepinnt

Was wir prüfen

Nach dem STARTTLS-Handshake fragen wir die TLSA-Einträge des Hosts unter _25._tcp.<mx-hostname> über einen validierenden Resolver ab und vergleichen das präsentierte Zertifikat mit jedem DNSSEC-validierten DANE-EE-Eintrag (Usage 3). Dieser Befund erscheint, wenn die Kette gegen keine vertrauenswürdige CA validiert — selbstsigniert oder anderweitig nicht vertrauenswürdig —, ein DANE-EE-Eintrag das Zertifikat aber pinnt.

Was dieses Ergebnis bedeutet

Der Server belegt seine Identität über DANE statt über eine Zertifizierungsstelle. Ein DANE-EE-Eintrag veröffentlicht das Zertifikat (oder seinen öffentlichen Schlüssel) DNSSEC-signiert im DNS; ein DANE-fähiger Absender prüft den Schlüssel gegen diesen Eintrag und braucht keine CA (RFC 7672 §3.1). Das Zertifikat ist damit keine defekte Kette und wird auch nicht so bewertet.

Warum das wichtig ist

Korrekt per Design. RFC 7672 erlaubt ausdrücklich — und DANE-Deployments nutzen häufig — selbstsignierte Zertifikate, die über DANE-EE gepinnt sind. Sie als ungültige Kette zu bewerten, würde das stärkere Authentifizierungsmodell bestrafen.
Nur für DANE-Absender. Absender ohne DANE validieren die Kette klassisch und sehen ein nicht vertrauenswürdiges Zertifikat. Ob das ins Gewicht fällt, hängt davon ab, wer dir Mail schickt.
DNSSEC ist der Anker. Der Pin ist nur so gut wie die DNSSEC-Kette, die ihn signiert; ein unsignierter TLSA-Eintrag beweist nichts und gilt nicht als Pin.

So behebst du das

Für DANE ist nichts zu tun. Sollen auch Absender ohne DANE die Verbindung validieren, setze zusätzlich ein CA-Zertifikat ein (z. B. von Let's Encrypt) und halte den TLSA-Eintrag dazu passend — ein 3 1 1-Eintrag über den öffentlichen Schlüssel übersteht Zertifikatserneuerungen, solange der Schlüssel gleich bleibt.

So fließt es in die Bewertung ein

Informativ, kein Abzug. Das sofortige F für eine nicht vertrauenswürdige Kette greift nicht, solange ein validierter DANE-EE-Eintrag zum Zertifikat passt; die DANE-Prüfungen selbst werden separat bewertet. Den Ablauf deckt der Pin nicht ab: Ein abgelaufenes Zertifikat behält sein sofortiges F, weil die meisten Absender weiterhin klassisch validieren. Siehe Bewertungsmethodik.

Evidenzbeispiel

$ dig +dnssec TLSA _25._tcp.mail.example.com +short
3 1 1 2ABDD2F9…   ← Usage 3 (DANE-EE), Selector 1 (SPKI), SHA-256
$ openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null \
    | openssl x509 -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
2abdd2f9…            ← passt zum TLSA-Eintrag