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. Ergänzung: Es gibt weitere Betroffene.
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?
Ergänzung: Es gibt weitere Betroffene
Der Blog-Leser hat mir im Nachgang noch eine E-Mail geschickt und schrieb, dass es auf reddit.com einen Post dazu gebe.
Ein Beitrag auf reddit.com
Ich habe nach einer kurzen Suche den reddit.com-Thread Mail.protection.outlook.com STARTTLS cert verify failed since ~June 15th, anyone else affected? gefunden. Der Betroffene schreibt, dass er seit etwa dem 15. Juni das Problem bei mehreren seiner Laravel-Anwendungen, die den Microsoft 365/Exchange-Konnektor verwenden (mail.protection.outlook.com auf Port 25, STARTTLS), habe, das diese folgende Fehlermeldung ausgeben:
Unable to connect with STARTTLS: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages: error:0A000086:SSL routines::certificate verify failed
Der Betroffene gibt an, dass sie die relevante Konfiguration auf seiner Seite nicht geändert habe. Es gilt:
Protokoll: SMTP
Host: xxx.mail.protection.outlook.com
Port: 25
Verschlüsselung: TLS
Nach den Recherchen des Betroffenen schrieb dieser ebenfalls, dass das Problem mit der Abkündigung der DigiCert Global Root CA (G1) zusammenzuhängen scheint. Mozilla und Chrome haben bereits im April das Vertrauen in diese Root-Zertifizierungsstelle aufgegeben. Der Betroffene schrieb: "Es sieht so aus, als würden die MX-Zertifikate von Microsoft für mail.protection.outlook.com immer noch auf diese alte G1-Root verweisen, anstatt auf die neuere G2-Root. Daher werde jeder Linux-Rechner, auf dem das Paket "ca-certificates" kürzlich aktualisiert wurde, die Zertifikatskette bei ausgehenden SMTP-Verbindungen ablehnen, was beim Betroffenen zeitlich mit dem Auftreten des Problems übereinstimmt.
Ein Beitrag auf bei NextCloud
Und es gibt den NextCloud Hilfe-Beitrag [SOLVED] M365/Office 365 SMTP Connector Fails after Linux ca-certificates Update (June 2026) vom 22. Juni 2026, der das gleiche Fehlerbild beschreibt. In diesem Beitrag wird ein Workaround (Download und Installation der alten Zertifikate für betroffene Linux-Versionen) vorgeschlagen, was aber die Sicherheit reduziert.
Eine dritte Fundstelle zu obigem Fehler habe ich in diesem Post gefunden. Bleibt in diesem Kontext zu hoffen, dass Microsoft dies irgendwann noch gebacken bekommt und das Zertifikate austauscht.
MVP: 2013 – 2016
. [deine-domain].o-v1.mx.microsoft verwenden, dort sollte es nicht klemmen. Kann man auch ohne DNSSEC aktivieren. MS Support ist eigentlich nur noch KI meistens schaut es kein Mensch an…
Ich bekomme im Moment auch:
Connecting to 52.101.170.0
CONNECTED(00000003)
depth=2 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
verify return:1
depth=1 C=US, O=DigiCert Inc, CN=DigiCert Cloud Services CA-1
verify return:1
depth=0 C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=mail.protection.outlook.com
verify return:1
—
Certificate chain
0 s:C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=mail.protection.outlook.com
i:C=US, O=DigiCert Inc, CN=DigiCert Cloud Services CA-1
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Aug 27 00:00:00 2025 GMT; NotAfter: Aug 26 23:59:59 2026 GMT
1 s:C=US, O=DigiCert Inc, CN=DigiCert Cloud Services CA-1
i:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Sep 25 00:00:00 2020 GMT; NotAfter: Sep 24 23:59:59 2030 GMT
—
was ein aktuelles Debian Trixie 13.5 (nicht Ubuntu) auch klaglos akzeptiert.
Das "DigiCert Cloud Services CA-1" ist nur ein Intermediate, welches seinerseits vom "DigiCert Global Root CA" signiert ist. Damit muß es nicht im Truststore liegen, sondern kann beim Handshake übermittelt werden.
Die CRL (crl3.digicert.com/DigiCertCloudServicesCA-1-g1.crl) wird geprüft und bemängelt es nicht, genausowenig ocspx.digicert.com.
Im Truststore liegen nur:
/usr/share/ca-certificates/mozilla/DigiCert_Assured_ID_Root_CA.crt
/usr/share/ca-certificates/mozilla/DigiCert_Assured_ID_Root_G2.crt
/usr/share/ca-certificates/mozilla/DigiCert_Assured_ID_Root_G3.crt
/usr/share/ca-certificates/mozilla/DigiCert_Global_Root_CA.crt
/usr/share/ca-certificates/mozilla/DigiCert_Global_Root_G2.crt
/usr/share/ca-certificates/mozilla/DigiCert_Global_Root_G3.crt
/usr/share/ca-certificates/mozilla/DigiCert_High_Assurance_EV_Root_CA.crt
/usr/share/ca-certificates/mozilla/DigiCert_TLS_ECC_P384_Root_G5.crt
/usr/share/ca-certificates/mozilla/DigiCert_TLS_RSA4096_Root_G5.crt
/usr/share/ca-certificates/mozilla/DigiCert_Trusted_Root_G4.crt
Du schreibst ja selbst „DigiCert_Global_Root_CA.crt" liegt im Truststore. Damit wird die Kette von CA-1 natürlich akzeptiert.
Die Verwendung der "DigiCert Cloud Services CA-1" lässt sich bei mir eindeutig nachvollziehen:
openssl s_client -starttls smtp -connect {some-tenant}.mail.protection.outlook.com:25 -showcerts
Connecting to 52.101.68.10
CONNECTED(00000003)
depth=2 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
verify return:1
depth=1 C=US, O=DigiCert Inc, CN=DigiCert Cloud Services CA-1
verify return:1
depth=0 C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=mail.protection.outlook.com
verify return:1
—
Certificate chain
0 s:C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=mail.protection.outlook.com
i:C=US, O=DigiCert Inc, CN=DigiCert Cloud Services CA-1
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
Allerdings wird unter Debian die Zertikatskette nicht in Frage gestellt. Die Verbindung kann ganz normal hergestellt werden.
Auch sind die Zertifikate nicht in der Sperrliste eingetragen. Eine Prüfung per OSCP liefert:
Cert VALIDATED: ok
cert not revoked by OCSP
Ich habe unter Debian Trixie (neuster Stand) getestet.
Das ohne den Vertrauensanker des Root-Zertifikats keine Verbindung hergestellt werden kann, ist logisch und richtig.
Frage wäre jetzt, ob Ubuntu die Zertifikate fälschlicherweise entfernt hat, oder ob andere Distributionen noch nicht so weit sind?
Dann ist dort das Zertifikat eben noch in ca-certificates enthalten schätze ich. Schau einfach mal nach. Bei Ununtu wurde es wie im Artikel steht zur Monatsmitte entfernt, was so auch ganz offiziell richtig ist IMHO.
pragmatischer Ansatz: Mails per starttls 587 oder ssl 465 übermitteln, wenn dort ein Zertifikat existiert.
erfordert Authentifizierung, aber das ist ja nicht das Problem, höre ich heraus.
In diesem Fall wird ganz bewusst über den MX Endpunkt und Port 25 gesendet, da keine Authentifizierung mit OAUTH möglich ist. Ist auch ein ganz normales und Supportetes Vorgehen:
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365
Ohne das Support Thema in Frage stellen zu wollen.
Ist das aber eigentlich der richtige Endpunkt und Port? *protection.* auf Port 25?
Ja, die MX bei Tenants mit Exchange Online folgen diesem Namensschema und Port 25 passt auch. Details findet man hier: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365
Als wir noch Sophos verwendet haben, konnte ich öfters anhand der Mail-Logs sehen, dass einzelne MX aus dem outlook.com-Cluster mit abgelaufenen Zertifikaten unterwegs waren. Meist war das nach ein paar Stunden behoben, aber naivierweise würde man erwarten, dass so ein riesiger Mail-Provider seine Infrastruktur besser im Griff hat. Das Gegenteil ist der Fall. Too big to fail.
> Das Gegenteil ist der Fall. Too big to fail.
Eher: Too fail to big.
Probleme, die man ohne Microslop nicht hat..
Das Problem ist hier aber hier aber eindeutig bei Ubuntu zu suchen, denn unter Debian und per Powershell passt das Zertifikat.
Äh nein, Digicert hat schon in 2023 angekündigt, dass die Zertifikate ab April 2026 auf die "Distrust" Liste kommen, also u.a. bei Mozilla und Chrome aus dem Truststore entfernt werden. Daher kann man den Fehler durchaus bei Microsoft suchen, dass die nicht rechtzeitig alle Endpunkte auf die neuen Root und Intermediate Zertifikate umgestellt haben.
so siehts aus.
Hardenize bemängelt das Zertifikat auch.
Beispiel: https://www.hardenize.com/report/paperandtea.com/1782768085#email
Von Kunden gab es aber noch keine Problemmeldungen.
Ich trage gleich noch was nach – es gibt weitere Betroffen.
Ich weiß nicht, ob es eine gute Idee ist, hier zu einen Tenant-Namen zu verlinken.
Sachverhalt lässt sich auch hier mit Debian 13 (trixie) bestätigen, Zertifikat wird aber nicht bemängelt ("Verification: OK").
Aber die Supportqualität erinnert erinnert mich an meinen aktuellen Fall mit der Deutschen Post: Anzeigeproblem (Seitenteile werden nicht geladen), das sich beliebig mit verschiedenen Browsern, Betriebssystemen und Netzwerkumgebungen reproduzieren lässt, aber nur mit einem bestimmten Account (andere Accounts haben das Problem im selben Browserprofil nicht). Das einzige, was man vom dortigen Support bekommt, sind irgendwelche sinnlosen Textbausteine einschließlich der Aufforderung, Dinge zu versuchen, die man im Mailverlauf schon detailliert als erfolglos geschildert hat…
Evtl. hilft es hier (https://techcommunity.microsoft.com/blog/exchange/trust-digicert-global-root-g2-certificate-authority-to-avoid-exchange-online-ema/4488311) einmal zu kommentieren und Nino Bilic, Greg Taylor und/oder Arindam Thokder zu erwähnen.
Gute Idee, nur leider wird jeder Kommentar von dem System direkt automatisiert wieder gekillt :)
Warum treten diese Fehler nur bei Linux-Relayhosts auf?
Wir relayen problemlos in exakt derselben Weise mit hMailServer, IIS SMTP oder Haraka per TLS an tenantname.mail.protection.outlook.com auf verschiedensten Windows Server-Versionen 2016 bis 2025.
Prüfen die Windows-Versionen die Gültigkeit der Zertifikatskette nicht?
Oder ist das Zertifikat noch im Windows-Cert-Store enthalten?
Wie kann ich das prüfen?
Das betroffene Root Zertifikat "DigiCert Global Root CA" hat noch eine Gültigkeit bis 10.11.2031, ist an sich also noch gültig. Und es befindet sich auch standardmäßig noch im Windows Zertifikatsspeicher. Damit ist die Zertifikatskette für Windows und Programme, die auf den Windows Zertifikatsspeicher zugreifen, weiterhin gültig.
DigiCert hatte aber, wie im Artikel verlinkt, schon 2023 angekündigt, diese Zertifikate vorher austauschen zu wollen und sie ab April 2026 auf die "Distrust" Liste zu setzen. Firefox und Chrome würden ab diesem Datum einem von diesem Root ausgestellten Zertifikat nicht mehr vertrauen (sollen).
Ubuntu z.Bsp. hat das zum Anlass genommen, um mit einem Update dieses Root Zertifikat aus deren integrierten CA-Liste zu entfernen. Daher dann die Probleme. Microsoft hat somit also den "Distrust" von DigiCert einfach nicht in Windows eingepflegt und auch noch verschusselt rechtzeitig alle ihre Zertifikate in den EXO Endpunkten zu erneuern, dass die alle die neuen CA und Intermediate Zertifikate verwenden.
@Daniel A.: Super. Danke für die verständliche Erklärung! Das macht klar, warum es unter Windows keine Probleme gibt.
nützt jetzt nicht viel, aber meine postfix SMTP relay auf RHEL10 haben aktuell noch keine Probleme zu *.mail.protection.outlook.com:25
I've been waiting for Microsoft to read their own docs and fix their mail systems for almost three months… I've installed the "DigiCert Global Root CA" root CA certificate on our mail system as well as telling people to avoid this Microsoft sh*t. (It has been problems delivering mails to Outlook since the start I set up a mail server.)