Wenn nicht Ihr Zertifikat schuld ist, sondern die Kette

Das DigiCert-CA-1-Drama bei Exchange Online – warum der Mailversand bricht, obwohl Ihr Zertifikat gültig ist

In den letzten Tagen häufen sich Berichte, dass der E-Mail-Versand an bzw. über Exchange Online plötzlich abbricht – mit TLS-Fehlern, obwohl am eigenen Setup nichts geändert wurde. Die Ursache liegt diesmal nicht beim eigenen Zertifikat, sondern in der Zertifikatskette: Ein bereits abgelaufenes Intermediate („DigiCert Cloud Services CA-1“) wird weiterhin von Endpunkten unter *.mail.protection.outlook.com ausgeliefert. Gegenstellen, die die Kette streng validieren, weisen die Verbindung ab.

Das ist ein lehrreicher Fall, weil er ein Muster zeigt, das in der Praxis regelmäßig für Fehldiagnosen sorgt: Das Blatt-Zertifikat ist gültig – und trotzdem schlägt TLS fehl.

Blatt ≠ Kette: Wo der Denkfehler passiert

Bei einer TLS-Verbindung prüft die Gegenstelle nicht nur das Server- (Blatt-) Zertifikat, sondern die gesamte Vertrauenskette bis zu einer im eigenen Trust Store verankerten Root. Stolperfallen entstehen an zwei Stellen:

So grenzen Sie das Problem sauber ein

Der schnellste Weg ist, sich die tatsächlich ausgelieferte Kette anzusehen – nicht das, was im Store stehen sollte, sondern was der Endpunkt wirklich sendet:

1. Ausgelieferte Kette anzeigen (OpenSSL):

openssl s_client -connect ihre-domain.mail.protection.outlook.com:25 \
  -starttls smtp -showcerts < /dev/null 2>/dev/null \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout

2. Ablaufdaten jedes Glieds prüfen (PowerShell, Windows):

$tcp = New-Object Net.Sockets.TcpClient('host', 443)
$ssl = New-Object Net.Security.SslStream($tcp.GetStream())
$ssl.AuthenticateAsClient('host')
$chain = New-Object Security.Cryptography.X509Certificates.X509Chain
$chain.Build($ssl.RemoteCertificate)
$chain.ChainElements | ForEach-Object {
    '{0,-45} {1}' -f $_.Certificate.Subject, $_.Certificate.NotAfter
}

Sehen Sie in der Ausgabe ein Intermediate mit einem NotAfter in der Vergangenheit, ist die Diagnose klar: Kettenproblem, nicht Blattproblem. Bei serverseitigen Cloud-Diensten wie Exchange Online liegt der Fix dann beim Anbieter – Ihre Aufgabe ist, es nachzuweisen und betroffene Mailflüsse zu identifizieren.

Checkliste: Kettenprobleme vermeiden statt jagen

• ✓ Monitoring auf die gesamte Kette ausweiten – nicht nur auf das Blatt-Zertifikat.
• ✓ Pro Endpunkt einen Schwellwert auf das kürzeste NotAfter der Kette setzen.
• ✓ Intermediate-Wechsel von CAs (DigiCert & Co.) aktiv verfolgen – nicht erst beim Ausfall reagieren.
• ✓ Bei Drittanbieter-Diensten: ausgelieferte Kette periodisch protokollieren, um Anbieterfehler beweisbar zu machen.
• ✓ Bei Verdacht erst die ausgelieferte Kette prüfen, dann den lokalen Trust Store – in dieser Reihenfolge.