tls.cert.hostname_shared_frontend

Zertifikat für Shared-Mail-Front-End

Was wir prüfen

Passt das Zertifikat nicht zum MX-Hostnamen, machen wir eine Sekundärprüfung: Passt es zum forward-bestätigten PTR-Hostnamen dieser IP? Verifiziert der PTR-Hostname gegen das Zertifikat (vollständiger x509-SAN-Abgleich, nicht nur Domain-Verwandtschaft) und ist keine strikte Validierungsrichtlinie veröffentlicht (MTA-STS enforce oder prüfbare DANE-TLSA-Einträge), mildern wir den harten Hostname-Mismatch zu dieser Warnung ab.

Was dieses Ergebnis bedeutet

Das Zertifikat gilt nicht für deinen MX-Hostnamen, deckt aber den eigenen PTR-bestätigten Hostnamen der Maschine ab. Typisch für ein Shared-Mail-Front-End — einen Spamfilter, Relay-Cluster oder das Mail-Gateway eines Hosters, bei dem dein MX-Name ein Alias für dessen Infrastruktur ist.

Absender mit opportunistischem TLS akzeptieren das: Der verschlüsselte Kanal kommt zustande, auch wenn der Name nicht zum MX passt. Absender mit strikten Richtlinien (MTA-STS, DANE) würden ablehnen.

Warum das wichtig ist

Reduzierte Sicherheit. Das Zertifikat belegt die Identität der Maschine unter ihrem eigenen Namen — nicht unter deinem. Das ist schwächer als ein Zertifikat, das den MX-Hostnamen direkt abdeckt.
Unverträglich mit strikten Richtlinien. Veröffentlichst du später MTA-STS im enforce-Modus oder DANE-TLSA-Einträge, verursacht diese Konstellation Zustellungsfehler bei Absendern, die die Richtlinien durchsetzen.
Akzeptierter Kompromiss. Viele gehostete Mail-Setups funktionieren absichtlich so — der Anbieter pflegt Zertifikate für seine Infrastruktur-Hostnamen, nicht für jeden MX-Alias seiner Kunden.

So behebst du das

Bitte deinen Mail-Hoster, deinen MX-Hostnamen in die Subject Alternative Names des Zertifikats aufzunehmen. Manche Anbieter bieten das im Admin-Panel an.
Oder nutze ein eigenes Zertifikat. Kontrollierst du den Server selbst, nimm den MX-Hostnamen ins Zertifikat auf:
```
certbot certonly --standalone \
    -d mail.example.com \
    -d mx-gateway.provider.example.net
```
Wäge den Kompromiss ab. Ohne Pläne für MTA-STS oder DANE ist der Befund informativ — für opportunistisches TLS funktioniert das Shared-Front-End-Setup.

So fließt es in die Bewertung ein

Ein Shared-Front-End-Zertifikat kostet 5 Punkte (Warnung) — statt der 20 Punkte eines vollen Hostname-Mismatch. Die Milderung entfällt, sobald eine strikte Richtlinie veröffentlicht ist: Mit MTA-STS enforce oder prüfbaren DANE-TLSA-Einträgen greift die volle tls.cert.hostname_mismatch-Strafe. Das vollständige Scoring-Modell steht in der Bewertungsmethodik.

Evidenzbeispiel

MX-Hostname: mail.example.com
IP: 203.0.113.42
PTR: gateway7.provider.example.net (forward-bestätigt)

Zertifikats-SANs: *.provider.example.net, provider.example.net
  → deckt mail.example.com nicht ab (MX-Hostname)
  → deckt gateway7.provider.example.net ab (PTR-Hostname) ✓
  → kein MTA-STS enforce / kein DANE TLSA → abgemildert zur Shared-Front-End-Warnung