tls.cert.hostname_mismatch

Zertifikats-Hostname stimmt nicht überein

Was wir prüfen

Wir verbinden uns mit jeder MX-IP über STARTTLS und prüfen, ob die Subject Alternative Names (SANs) des Zertifikats den MX-Hostnamen enthalten. Wildcard-Abgleich folgt den RFC-6125-Regeln; das veraltete Common-Name-Feld (CN) ignorieren wir — kein moderner Validator nutzt es noch.

Jede aufgelöste IP wird einzeln geprüft. Verschiedene IPs hinter demselben MX-Hostnamen können unterschiedliche Zertifikate präsentieren — eine IP kann bestehen, während eine andere durchfällt.

Was dieses Ergebnis bedeutet

Das von dieser IP präsentierte Zertifikat gilt nicht für den MX-Hostnamen. Es kann für einen anderen Hostnamen völlig gültig sein — aber es beweist nicht, dass dieser Server der ist, auf den der MX-Eintrag zeigt.

Warum das wichtig ist

Identitätsfehler. Das Zertifikat authentifiziert den Server nicht als das erwartete Mail-Ziel. Ein Angreifer, der die Verbindung abfängt, könnte genauso gut ein fremdes Zertifikat vorzeigen.
Strikte Richtlinien schlagen fehl. Absender mit MTA-STS oder DANE verweigern die Zustellung, wenn das Zertifikat nicht zum erwarteten Hostnamen passt.
Häufige Fehlkonfiguration. Typisch, wenn ein Server viele Domains hostet, aber ein Standardzertifikat präsentiert, das nur einige abdeckt — oder wenn der MX-Eintrag auf einen Hostnamen zeigt, der in den SANs fehlt.

So behebst du das

Prüfe, welche Namen das aktuelle Zertifikat abdeckt:

openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com 2>/dev/null | \
    openssl x509 -noout -ext subjectAltName

Nimm den MX-Hostnamen ins Zertifikat auf. Bei Let's Encrypt:

certbot certonly --standalone \
    -d mail.example.com \
    -d mx1.example.com \
    -d mx2.example.com

Oder nutze ein Wildcard-Zertifikat, wenn viele MX-Hostnamen unter einer Domain laufen:

certbot certonly --manual --preferred-challenges dns \
    -d "*.example.com" -d example.com

Neu laden und prüfen:

systemctl reload postfix
openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com 2>/dev/null | \
    openssl x509 -noout -ext subjectAltName

Der MX-Hostname muss jetzt in der SAN-Liste stehen.

So fließt es in die Bewertung ein

Ein Hostname-Mismatch kostet 20 Punkte in der TLS-Kategorie. Deckt das Zertifikat stattdessen den forward-bestätigten PTR-Hostnamen der IP ab (ein geteiltes Mail-Frontend), mildert sich der Befund zu tls.cert.hostname_shared_frontend mit 5 Punkten Abzug. Das vollständige Scoring-Modell steht in der Bewertungsmethodik.

Evidenzbeispiel

$ openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com 2>/dev/null | \
    openssl x509 -noout -subject -ext subjectAltName
subject=CN = other.example.net
X509v3 Subject Alternative Name:
    DNS:other.example.net, DNS:*.other.example.net

Der MX-Hostname mail.example.com fehlt in der SAN-Liste.