„Server certificate not verified“: Wenn E-Mails an Hotmail und Outlook plötzlich hängen bleiben

Anfang Juli fiel bei uns ein unauffälliges, aber ärgerliches Problem auf: E-Mails an Adressen bei hotmail.com und outlook.com blieben in der Warteschlange hängen und wurden nach drei Tagen als unzustellbar an die Absender zurückgeschickt. Alle anderen Empfänger funktionierten normal. Weil nur ein Teil des Mailverkehrs betroffen war, wirkte das Ganze zunächst wie ein sporadisches Problem, war aber ein klar reproduzierbarer Fehler mit einer einzigen Ursache. Dieser Beitrag beschreibt, was passiert war, damit andere Administratoren mit demselben Symptom nicht lange suchen müssen.

Das Symptom

Im Maillog tauchte bei jedem Zustellversuch an Microsoft immer dieselbe Zeile auf:

• status=deferred (Server certificate not verified)
• Antwortcode dsn=4.7.5, also ein temporärer Fehler, der Postfix zum erneuten Zustellen veranlasst
• Nach Ablauf der Queue-Lebensdauer dann status=expired, returned to sender

Entscheidend ist: Der Mailserver lehnt hier nicht die Gegenstelle ab, weil deren Zertifikat ungültig wäre. Er kann die Zertifikatskette schlicht nicht bis zu einer vertrauenswürdigen Wurzel auflösen und bricht deshalb ab.

Die Ursache: eine entfernte Wurzel im Truststore

Auslöser war ein Update des Pakets ca-certificates, das den systemweiten Zertifikatsspeicher pflegt. Mit diesem Update wurde die alte DigiCert Global Root CA aus der aktiven Liste genommen. Sichtbar wird das in /etc/ca-certificates.conf, wo die betroffene Wurzel mit einem vorangestellten Ausrufezeichen deaktiviert ist:

• !mozilla/DigiCert_Global_Root_CA.crt

Neuere DigiCert-Wurzeln (G2, G3, G5) bleiben im Speicher, die alte Global Root aber nicht. Das ist normalerweise unkritisch, weil die meisten Anbieter längst auf die neueren Ketten umgestellt haben. Microsoft liefert für seine Mailserver jedoch weiterhin eine Kette aus, die genau in dieser alten Wurzel endet: Das Serverzertifikat von mail.protection.outlook.com wird über die Zwischenstelle DigiCert Cloud Services CA-1 auf die DigiCert Global Root CA zurückgeführt. Fehlt diese Wurzel lokal, lässt sich die Kette nicht mehr verifizieren.

Warum es überhaupt einen harten Fehler gab: MTA-STS

Für die normale SMTP-Zustellung gilt Transportverschlüsselung als opportunistisch: Kann ein Zertifikat nicht geprüft werden, wird trotzdem verschlüsselt oder notfalls unverschlüsselt zugestellt. Damit wäre die Mail durchgegangen. Zum echten Fehler wird die fehlende Wurzel erst durch MTA-STS.

Microsoft veröffentlicht für seine Domains eine MTA-STS-Policy im Modus enforce. Diese Policy verlangt vom sendenden Server eine gültige, verifizierte TLS-Verbindung mit passendem Zertifikat. Kann der Absender das Zertifikat nicht verifizieren, darf er die Mail nicht ausliefern. Genau diese Kombination war die Falle:

• Ohne MTA-STS: Zertifikat nicht prüfbar, Zustellung trotzdem, keine Störung.
• Mit MTA-STS im enforce-Modus: Zertifikat nicht prüfbar, Zustellung verweigert, Mail bleibt liegen.

Das erklärt auch, warum ausgerechnet Microsoft betroffen war und viele andere Anbieter nicht: Es traf jene Empfänger, die eine strikte MTA-STS-Policy erzwingen und gleichzeitig eine Kette über die entfernte Wurzel ausliefern.

So lässt sich die Diagnose bestätigen

Ein einzelner Handshake vom betroffenen Server zeigt das Problem sofort. Der folgende Aufruf baut testweise eine TLS-Verbindung zum Microsoft-Mailserver auf:

• openssl s_client -connect hotmail-com.olc.protection.outlook.com:25 -starttls smtp

Bei fehlender Wurzel endet die Ausgabe mit Verify return code: 20 (unable to get local issuer certificate). Wer Postfix einsetzt, kann zusätzlich mit posttls-finger und erzwungener Sicherheitsstufe prüfen, ob eine verifizierte Verbindung zustande kommt. Vor dem Fix meldet das Werkzeug einen Fehler, danach eine Verified TLS connection.

Die Lösung: die fehlende Wurzel gezielt wieder aufnehmen

Die DigiCert Global Root CA ist unverändert gültig und weiterhin vertrauenswürdig; sie wurde nur aus der Standardauswahl genommen. Statt das gesamte Paket-Update zurückzudrehen, nimmt man die Wurzel gezielt wieder auf. Bewährt hat sich der Weg über den lokalen Zertifikatsordner, der bei Systemupdates nicht überschrieben wird:

1. Die PEM-Datei der DigiCert Global Root CA nach /usr/local/share/ca-certificates/ legen (Dateiendung .crt)
2. Den Truststore mit update-ca-certificates neu erzeugen
3. Den Mailserver die neue Vertrauensbasis lesen lassen, bei Postfix genügt postfix reload

Wichtig ist, die Echtheit der Wurzel vor dem Einspielen zu prüfen, am besten über den bekannten SHA-256-Fingerabdruck der DigiCert Global Root CA. Erst danach sollte sie in den Truststore wandern. Nach dem Reload verifiziert der Server die Microsoft-Kette wieder, und die zuvor liegen gebliebenen Mails werden beim nächsten Queue-Lauf zugestellt.

Was man daraus mitnehmen kann

• "Server certificate not verified" heißt fast nie, dass die Gegenstelle ein schlechtes Zertifikat hat. Es heißt, dass der eigene Server die Kette nicht auflösen kann, meist wegen einer fehlenden Wurzel.
• Updates von ca-certificates können Zustellprobleme auslösen, obwohl am Mailserver selbst nichts verändert wurde. Nach solchen Updates lohnt ein Testhandshake zu den wichtigsten Zielanbietern.
• MTA-STS verwandelt eine harmlose Warnung in einen Zustellstopp. Das ist gewollt und richtig, macht die Fehlersuche aber weniger offensichtlich, weil nur einzelne Empfängerdomains betroffen sind.
• Der lokale Zertifikatsordner ist der sichere Ort für Nachbesserungen, weil er Systemupdates übersteht.

Für unsere Kundinnen und Kunden war der Fall nach dem Fix erledigt: Die Zustellung an Microsoft-Adressen läuft wieder zuverlässig. Wir haben den Beitrag trotzdem geschrieben, weil das Zusammenspiel aus entfernter Wurzel und erzwungenem MTA-STS ein Muster ist, das jeden Mailserver-Betreiber treffen kann, und weil die Fehlermeldung allein leicht in die falsche Richtung führt.