Exchange Online, der Microsoft Support und das CA-1-TLS-Zertifikatskettendrama

Ein Blog-Leser hat mich kontaktiert, da er in ein Problem mit TLS-Zertifikaten bei Exchange Online gelaufen ist. Der E-Mail-Versand funktioniert nicht mehr, weil ein Microsoft TLS-Zertifikate abgewiesen wurde. Konkret sieht es so aus, dass das abgelaufene DigiCert Cloud Services CA-1 weiter von *.mail.protection.outlook.com verwendet wird. Das geht aber unter Ubuntu schief, da das CA-1 entfernt wurde. Der Leser versuchte das Problem mittels des Microsoft Supports zu lösen, was aber in einem "TLS-Zertifikatskettendrama" endete und bis jetzt versandet ist. Es interessiert nun, ob ein Denkfehler, ein Einzelfall oder ein generelles Problem vorliegt.

Eine spezielle E-Mail-Konstellation des Lesers

Blog-Leser Georg S. hatte mich am Freitag-Nachmittag, den 26. Juni 2026, per E-Mail mit dem Betreff "Microsoft Support und TLS Zertifikatskettendrama" kontaktiert. Dazu schrieb er mir, dass er mehrere Linux-Systeme betreibe, die unter anderem E-Mails per SMTP-Relay über Exchange Online Protection (MX-Host *.mail.protection.outlook.com, STARTTLS auf Port 25) an Microsoft 365 versenden. Dazu schrieb Georg: "Mir ist bewusst, dass dieser Weg heute nicht mehr die bevorzugte Variante ist, er wird von Microsoft aber weiterhin offiziell unterstützt."

Mail-Versand plötzlich gestört

Vor wenigen Tagen stellte der Leser fest, dass der Mailversand plötzlich nicht mehr funktionierte. Ursache war nach der Analyse eine fehlgeschlagene TLS-Zertifikatsprüfung. Das Problem ließ sich reproduzierbar eingrenzen, denn die von Microsoft bei MX-Host präsentierte TLS-Zertifikatskette lautet aktuell:

mail.protection.outlook.com

• DigiCert Cloud Services CA-1
• DigiCert Global Root CA

Auf einem vollständig aktualisierten Ubuntu 22.04 (aktuelles ca-certificates-Paket) liefert bereits ein einfacher Test mit der Anweisung:

openssl s_client -starttls smtp -connect <tenant>.mail.protection.outlook.com:25 -showcerts

laut Leser Georg das nachfolgende Ergebnis:

Verify return code: 20 (unable to get local issuer certificate)

Auffällig dabei sei, schrieb Georg, dass das Intermediate DigiCert Cloud Services CA-1 von DigiCert Global Root CA signiert wurde. Die so präsentierte Zertifikatskette verweist somit auf diese Root-Zertifikat.

Da war doch was mit einer DigiCert-G1-Ablösung

Hier im Blog gibt es den Beitrag MC1193408: Zertifikatänderung für Microsoft Entra bis Jan. 2026 vom Dezember 2025. Botschaft in kurz: Microsoft wollte im Januar 2026 das DigiCert Global Root G1 in Entra auf das neue DigiCert Global Root G2 umstellen. Administratoren in Unternehmen mussten laut Supportbeitrag sicherstellen, dass dieses neue Zertifikat genutzt wird, weil sonst die Entra-Anmeldung scheitern werde, hieß es von Microsoft. Dort ist also bekannt, dass das DigiCert Global Root G1 zurückgezogen ist.

Georg schrieb mir dazu: "Genau diese Root wurde jedoch im Zuge der DigiCert-G1-Ablösung zum 15.04.2026 (siehe DigiCert root and intermediate CA certificate updates 2023) als nicht mehr vertrauenswürdig markiert". In dieser Folge wurde dieses Root-Zertifikat aus den aktuellen Mozilla-Truststores entfernt. Es ist also folglich auch seit kurzem im aktuellen Ubuntu-ca-certificates-Paket nicht mehr enthalten (siehe Package "ca-certificates" unter UbuntuUpdates.org).

Dadurch trat das Problem, dass E-Mails nicht mehr versandt werden konnten, beim Leser erstmals auf. Und dies, obwohl an den betroffenen Systemen selbst keine Änderungen vorgenommen wurden (abgesehen von der Aktualisierung des Pakets ca-certificates).

Wie sag ich es dem MS-Support?

Was macht man, wenn man als Microsoft-Kunde in ein solches Problem rauscht? Richtig, man kontaktiert den Microsoft-Support. Denn da sitzen ja Leute, die Ahnung haben – genau deshalb geht ja alle Welt in die Cloud, um keine eigene Expertise mehr vorhalten zu müssen. Microsoft verdient ja Milliarden mit der Cloud und gibt – so Stimmen aus der Leserschaft – auch Milliarden aus, dass das alles läuft. Die machen inzwischen zwar viel mit KI bei Microsoft, aber der Support müsste wissen, was Sache ist.

Erster Austausch: "Wir nutzen keine G1-Roots mehr"

Der Leser erlebte aber einen anderen Support und schrieb mir dazu: "Besonders kurios wurde es anschließend im Austausch mit dem Microsoft-Support. Zunächst wurde mir erklärt, die EOP-Endpunkte würden keine G1-Roots mehr verwenden und ich erhielt sogar das aktuelle Microsoft-Root-Zertifikatspaket. Darin ist die von mir angesprochene DigiCert Global Root CA lustigerweise auch nicht mehr enthalten."

OpenSSL-Ausgabe zeigt G1-Root-Zertifikat

Also alles in grün? Der Leser hat sich dann die Ausgabe des obigen openssl-Befehls anzeigen lassen. Der Leser schrieb dazu: "Der OpenSSL-Output des Microsoft-MX-Endpunkts zeigt jedoch eindeutig":

Issuer: C=US, O=DigiCert Inc, CN=DigiCert Cloud Services CA-1

Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=mail.protection.outlook.com

Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA

Subject: C=US, O=DigiCert Inc, CN=DigiCert Cloud Services CA-1

Die outlook.com-Mails werden eindeutig noch mit dem DigiCert Cloud Services CA-1 abgesichert.

Ernüchternder Austausch mit dem MS-Support

Als der Leser dann beim Microsoft-Support nachbohrte und mit den obigen Erkenntnissen konfrontierte, erlebte er die nächste Überraschung. O-Ton des Lesers: Damit Du eine Vorstellung bekommst, warum ich mich inzwischen an Dich wende, hier zwei Originalzitate aus dem Microsoft-Support:

Nach Rücksprache mit unserem Third-Level-Support möchten wir Sie darüber informieren, dass die Bereitstellung oder Verwaltung von Betriebssystem-Zertifikaten außerhalb unseres Supportumfangs liegt. Unser Support konzentriert sich ausschließlich auf cloudbezogene Themen.

Ich habe mal die Antwort des Microsoft-Supports, den der Leser mir im Original bereitstellte, hier eingefügt:

Die von Microsoft betriebenen MX-Server sind Teil einer global geteilten Infrastruktur, die Millionen von Postfächern weltweit bedient. Die dort angebotenen Cipher Suites werden zentral von den Microsoft-Engineering-Teams festgelegt, um eine gute Balance zwischen hoher Sicherheit und möglichst breiter SMTP‑Kompatibilität sicherzustellen. Daher ist es leider nicht möglich, diese Einstellungen individuell pro Tenant oder über den Support anzupassen.

Ich verstehe sehr gut, dass Ihnen ein möglichst hohes Sicherheitsniveau wichtig ist. Genau hier kann ich Sie aber beruhigen: Für Ihre Domäne ist bereits der bestmögliche Schutz aktiv – nämlich die Kombination aus DANE und DNSSEC. Dadurch wird sichergestellt, dass TLS-Verbindungen zwingend verwendet werden und Zertifikate verifiziert sind.

Die älteren Cipher Suites, die Sie eventuell sehen, dienen ausschließlich als Fallback-Optionen. Sie kommen nur dann zum Einsatz, wenn ein sendender Mailserver keine moderneren, stärkeren Verfahren unterstützt.

Der Leser schrieb mir dazu: "Ich habe den Sachverhalt inzwischen viermal mit allen technischen Nachweisen beschrieben. Die letzte und neueste Antwort von heute ist nun (nach 2 Tagen Wartezeit…) das hier, nachdem ich das bereits in der ersten Meldung dargelegt hatte":

Könnten Sie uns bitte noch kurz mitteilen, welches System konkret von dem Problem betroffen ist (z. B. Betriebssystem, Version) und wie dieses mit Ihrem Microsoft-Tenant in Zusammenhang steht?

Mir liegt der gesamte Mail-Austausch mit dem Microsoft Support vor, ich erspare mir aber die Einzelheiten. Der Leser hat in den Mails technisch sehr klar beschrieben, was er für ein Problem hat, was er getestet hat und wo er das Problem sieht. Das ist alles in obigem Text von mir offen gelegt worden.

Böse Zungen, oder Will Dormann hätte geschrieben: "Kein Wunder, wenn der Mann kein Video einreicht, das zeigt, wo es klemmt, kann Microsoft das nicht verstehen". Aber das wäre jetzt unfaire Dialektik, denn beim Thema von Will Dormann geht es um das Microsoft Security Response Center (MSRC) und gemeldete Schwachstellen.

Das Verhalten ist reproduzierbar, hat jemand eine Erklärung?

Der Leser schrieb mir, dass er das Verhalten auf drei unabhängigen Ubuntu-22.04-Systemen sowie gegen mehrere verschiedene *.mail.protection.outlook.com-Hosts reproduzieren konnte. Damit scheint weder der Tenant noch der Server selbst ursächlich zu sein. Das heißt das Thema dürfte also grundsätzlich alle Installationen betreffen, die weiterhin per SMTP-Relay über Exchange Online Protection arbeiten und eine strikte TLS-Zertifikatsprüfung durchführen.

Zum Vergleich hat der Leser die Zertifikatskette auf demselben System gegen  smtp.office365.com:587 getestet und festgestellt, dass das problemlos (Verify return code: 0) validiert wird. Dort liegt aber korrekterweise DigiCert Global Root G2 zugrunde. Das Problem betrifft ausschließlich die MX-Hosts *.mail.protection.outlook.com auf Port 25, schrieb der Leser.

Im Abschlusssatz merkte Georg an: "Vielleicht kannst Du das einmal auf einem aktuellen Linux-System nachstellen oder den Sachverhalt aufgreifen. Mich würde vor allem interessieren, ob andere Administratoren dasselbe Verhalten beobachten." Ich selbst kann da wenig tun, habe keinerlei M365-Tenants. Daher gebe ich die Frage an die Leserschaft weiter. Gibt es einen "Denkfehler" in der obigen Beschreibung oder eine Erklärung? Oder lässt sich das aus der Leserschaft bestätigen?