Ein abgelaufenes Zertifikat legte Microsoft 365 lahm — wie viele laufen bei Ihnen ab?

Was ist am 31. August passiert?

Am 31. August 2026 waren zentrale Microsoft-365-Dienste großflächig nicht erreichbar — betroffen waren unter anderem Exchange Online, Outlook und Teams. Microsoft führte die Störung im eigenen Service-Health-Dashboard unter der Kennung EX1464935. Als Ursache gilt Berichten zufolge ein abgelaufenes internes Zertifikat in der Anmelde-Komponente — bestätigt ist das nicht, und für die Lehre daraus ist es auch nicht entscheidend.

Kein Angriff, keine überlastete Leitung, kein Rechenzentrumsbrand. Ein Datum war erreicht — und ein Dienst, der Hunderte Millionen Postfächer trägt, stellte die Arbeit ein.

Für Microsoft war das ein peinlicher Betriebstag. Interessanter ist die Frage, die sich daraus für jeden Betrieb ergibt: Wie viele Zertifikate laufen bei Ihnen, und wann laufen sie ab? Wer darauf nicht innerhalb einer Minute antworten kann, hat dieselbe Bauart von Risiko im Haus — nur ohne Krisenstab.

Warum legt ein abgelaufenes Zertifikat gleich alles lahm?

Ein Zertifikat ist ein Ausweis. Es bestätigt, dass ein Server wirklich der ist, der er zu sein vorgibt, und es verschlüsselt die Verbindung. Jeder Ausweis hat ein Ablaufdatum — typischerweise ein Jahr, bei öffentlichen TLS-Zertifikaten inzwischen deutlich kürzer.

Das Trügerische daran ist der Verlauf: Ein Zertifikat wird nicht langsam schlechter. Es funktioniert bis zur letzten Sekunde einwandfrei — und ist in der nächsten Sekunde ungültig. Gegenstellen brechen die Verbindung dann bewusst ab, denn genau das ist ihre Aufgabe: einem abgelaufenen Ausweis nicht zu trauen.

Deshalb sieht der Ausfall auch nie nach „Zertifikat“ aus. Er sieht aus wie: Der VPN-Client verbindet nicht mehr. Outlook fragt endlos nach dem Passwort. Die Notebooks kommen nicht mehr ins WLAN. Die Kasse erreicht die Warenwirtschaft nicht. Bis jemand die richtige Fehlermeldung liest, vergeht die halbe Störung.

Wo laufen in Ihrem Unternehmen überhaupt Zertifikate?

Fast überall — und die wenigsten davon stehen auf einer Liste. Typisch für einen mittelständischen Betrieb:

• VPN und Firewall: Zugangszertifikate für Home­office und Außenstellen — läuft es ab, kommt niemand mehr von außerhalb ins Netz.
• WLAN mit 802.1X/RADIUS: Geräte authentifizieren sich per Zertifikat. Ablauf heißt: das halbe Haus steht ohne Funk da.
• Mail- und Terminalserver: Exchange, Remote-Desktop-Gateway, Reverse Proxy.
• Website und Kundenportale: das öffentliche TLS-Zertifikat — hier merken es die Kunden zuerst.
• Interne Zertifizierungsstelle (CA): die eigene Ausgabestelle. Läuft ihr Zertifikat ab, werden schlagartig alle davon ausgestellten ungültig.
• Fachanwendungen und Schnittstellen: DATEV, Warenwirtschaft, EDI-Anbindungen, Maschinensteuerungen im Produktionsnetz.
• Geräte- und Code-Signaturen: Signierte Skripte und Installationspakete, die nach Ablauf nicht mehr starten.

Die unangenehme Eigenschaft dieser Liste: Sie wächst mit jedem Projekt — aber niemand ist dafür zuständig, sie zu pflegen.

Warum fällt es fast immer erst beim Ausfall auf?

Weil die Erinnerung an den falschen Stellen liegt. Drei Muster wiederholen sich:

Die Mail geht an eine Person, nicht an den Betrieb. Der Anbieter warnt 30 Tage vorher — an die Adresse, die beim Kauf angegeben wurde. Sitzt derjenige inzwischen woanders oder ist im Urlaub, verschwindet die Warnung.

Das Zertifikat wurde „einmal eingerichtet“. Bei der Installation vor drei Jahren hat es funktioniert, seither hat es niemand angefasst. Wer es damals gemacht hat, weiß es — nur steht das nirgends.

Die Überwachung prüft Verfügbarkeit, nicht Ablauf. Klassisches Monitoring meldet, wenn ein Dienst nicht mehr antwortet. Ein Zertifikat, das in 14 Tagen abläuft, antwortet aber tadellos — bis es das nicht mehr tut.

Das Ergebnis ist immer dasselbe: Der Ablauf ist der einzige planbare Ausfall der IT — und trotzdem trifft er die meisten Betriebe unvorbereitet.

Wie bekommen Sie Zertifikate unter Kontrolle?

Der Aufwand ist überschaubar, wenn man es einmal ordentlich macht:

• Inventar anlegen. Eine Liste mit Zweck, System, Aussteller, Ablaufdatum und einer verantwortlichen Rolle. Eine Tabelle genügt fürs Erste — keine Liste zu haben, genügt nicht.
• Automatisch erneuern, wo es geht. Öffentliche TLS-Zertifikate lassen sich per ACME automatisiert verlängern, interne über die eigene CA per Auto-Enrollment. Was automatisch läuft, kann nicht vergessen werden.
• Auf Sammeladressen umstellen. Ablaufwarnungen gehören an ein Postfach, das mehrere Menschen lesen — nie an eine persönliche Adresse.
• Ablauf überwachen, nicht nur Erreichbarkeit. Ein Check, der 30 und 7 Tage vorher ein Ticket erzeugt, kostet einmalig eine Stunde Einrichtung.
• Erneuerung proben. Bei den kritischen Systemen — VPN, WLAN, Mail — einmal bewusst durchspielen, wer sie wie tauscht. Im Ernstfall ist das keine Zeit zum Nachlesen.
• Beim Weggang mitdenken. Verlässt jemand das Unternehmen, gehören seine Zertifikatsverantwortungen genauso übergeben wie seine Schlüssel.

Was sollten Sie als Nächstes tun?

Nehmen Sie sich diese Woche eine halbe Stunde und beantworten Sie drei Fragen: Welche Zertifikate haben wir? Wann laufen sie ab? Wer bekommt die Warnung? Wenn eine der drei Antworten „weiß ich nicht“ lautet, haben Sie den nächsten ungeplanten Betriebsstillstand bereits im Kalender stehen — Sie kennen nur das Datum noch nicht.

Der Microsoft-Ausfall ist dabei die günstigste Erinnerung, die man bekommen kann: Er hat Sie nichts gekostet außer einem unruhigen Montag. Wie sehr Cloud-Abhängigkeit generell ein Betriebsrisiko ist, haben wir in Wenn Microsoft ausfällt, steht der Betrieb still aufgeschrieben — dieser Beitrag ist die Version davon, die Sie selbst in der Hand haben.

Wenn Sie das Zertifikats-Inventar nicht selbst aufbauen wollen: Wir erheben es im Rahmen der Betreuung und hängen die Überwachung an unser Monitoring, damit der Ablauf zum Ticket wird statt zum Ausfall.