Bildquelle: Bildquelle: Pexels / Pixabay / https://www.pexels.com/photo/273153/
Kurz gesagt Öffentliche TLS-Zertifikate bestätigen, dass ein Browser wirklich mit der richtigen Website oder einem passenden Dienst spricht und die Verbindung verschlüsselt aufgebaut wird. Für Nutzer ist das meist nur das Schloss im Browser. Für den IT-Betrieb ist es ein Ablaufdatum mit Ausfallrisiko. Wenn Zertifikate künftig deutlich kürzer gültig sind, reicht eine gepflegte Erinnerungsliste nicht mehr aus.
Das CA/Browser Forum hat mit Ballot SC081v3 einen Stufenplan beschlossen, der die maximale Laufzeit öffentlich vertrauenswürdiger TLS-Zertifikate und die Wiederverwendung von Validierungsdaten schrittweise verkürzt. Die technische Debatte klingt nach PKI-Detail, trifft aber den Alltag von Service Ownern, Plattformteams und Helpdesks. Jedes vergessene Zertifikat kann aus einem stabilen Service in wenigen Minuten eine Störung machen, weil Browser, Schnittstellen oder mobile Apps die Verbindung ablehnen.
Ein TLS-Zertifikat ist ein digitaler Nachweis für eine Domain oder einen Dienst. Es wird von einer Zertifizierungsstelle ausgestellt und hat ein festes Ablaufdatum. Kürzere Laufzeiten sollen das Risiko alter oder falsch ausgestellter Zertifikate senken. Gleichzeitig steigt aber der operative Druck, Erneuerung, Kontrolle und Nachweis sauber zu automatisieren.
Das Problem wandert vom Einkauf in den Betrieb
Lange Zeit wurde Zertifikatsmanagement in manchen Organisationen wie eine Beschaffungsaufgabe behandelt. Jemand bestellte ein Zertifikat, legte es ab, trug ein Datum in einen Kalender ein und hoffte, dass vor Ablauf rechtzeitig jemand reagiert. Diese Arbeitsweise war schon bei längeren Laufzeiten riskant. Bei kürzeren Laufzeiten wird sie zum Betriebsrisiko.
Für ITSM ist der Punkt nicht, welche Zertifizierungsstelle genutzt wird. Entscheidend ist die Frage, welcher Service betroffen ist, wer die technische Erneuerung auslöst, wer die Domainvalidierung verantwortet, welche Tests nach dem Wechsel nötig sind und wie Ausnahmen sichtbar bleiben. Ein Zertifikat ist damit kein isoliertes Sicherheitsobjekt. Es hängt an Servicekatalog, Konfigurationsdaten, Change-Prozess, Monitoring und Incident Management.
Inventar ist nur der Anfang
Der erste praktische Schritt ist ein vollständiges Inventar. Dazu gehören öffentliche Websites, APIs, interne Portale mit öffentlichem Zertifikat, Load Balancer, Reverse Proxys, CDN-Konfigurationen, externe SaaS-Anbindungen und Zertifikate in mobilen oder eingebetteten Anwendungen. Gerade an Schnittstellen zeigt sich oft, dass die offizielle Liste kürzer ist als die echte Betriebslandschaft.
Ein gutes Inventar beantwortet mehr als die Frage nach dem Ablaufdatum. Es nennt den Service, die technische Plattform, den fachlichen Owner, den technischen Owner, die Erneuerungsmethode, die Validierungsart, den Fallback und den letzten erfolgreichen Test. Ohne diese Informationen entstehen im Störungsfall Suchketten. Dann muss erst geklärt werden, wem eine Domain gehört, welches Team Zugriff auf DNS hat und ob ein automatischer Prozess wirklich alle Zielsysteme erreicht.
Automatisierung braucht einen geprüften Rückweg
Die naheliegende Antwort auf kürzere Laufzeiten lautet Automatisierung. Protokolle wie ACME können Zertifikate automatisch ausstellen und erneuern. Das ist richtig, aber nicht automatisch ausreichend. Ein Erneuerungsprozess muss überwacht, protokolliert und getestet werden. Sonst ersetzt die Organisation eine manuelle Erinnerung durch einen stillen Automaten, dessen Fehler erst am Ablaufdatum auffällt.
Wichtig ist deshalb ein Betriebsmodell mit klaren Kontrollpunkten. Ein erfolgreicher Antrag ist noch kein erfolgreicher Rollout. Das neue Zertifikat muss auf dem richtigen System liegen, vom Dienst geladen werden, zur Domain passen, die komplette Zertifikatskette enthalten und nach außen geprüft werden. Bei kritischen Services gehört außerdem ein Rückweg dazu. Wer nach einer fehlerhaften Erneuerung nicht weiß, wie der letzte funktionierende Stand wiederhergestellt wird, hat kein belastbares Verfahren.
Monitoring darf nicht nur Rot zeigen
Viele Überwachungen melden ablaufende Zertifikate erst sehr spät oder nur an technische Postfächer. Für einen serviceorientierten Betrieb reicht das nicht. Warnungen brauchen Vorlauf, Priorität und Zuständigkeit. Ein Zertifikat für eine öffentliche Kundenplattform braucht eine andere Reaktion als ein Testsystem. Ein Zertifikat, das in drei Tagen abläuft und keinen Owner hat, ist kein Hinweis, sondern ein akuter Steuerungsfall.
Sinnvoll sind mehrere Schwellen. Frühwarnungen zeigen, ob der automatische Prozess grundsätzlich arbeitet. Mittlere Warnungen lösen ein Ticket mit Owner und Zieltermin aus. Kritische Warnungen eskalieren an Betriebsführung und Serviceverantwortliche. Zusätzlich sollte der Servicekatalog anzeigen, welche Services von einem Zertifikat abhängen. So wird aus einer technischen Ablaufmeldung eine verständliche Betriebsaufgabe.
Changes werden kleiner, aber häufiger
Kürzere Laufzeiten bedeuten nicht, dass jeder Zertifikatstausch ein großer Change werden muss. Im Gegenteil. Das Ziel sollte ein standardisierter, risikoarmer Ablauf sein. Dafür muss die Organisation aber wissen, welche Wechsel vollständig automatisiert und getestet sind und welche noch manuelle Schritte enthalten. Nur dann lässt sich entscheiden, was als Standard Change laufen kann und wo zusätzliche Freigabe nötig bleibt.
Besonders heikel sind Sonderfälle. Dazu zählen Wildcard-Zertifikate, manuelle DNS-Freigaben, Altgeräte, Partneranbindungen, Zertifikate mit fest hinterlegten Fingerprints oder Dienste, die nach einem Wechsel neu gestartet werden müssen. Diese Fälle gehören nicht in eine Randnotiz. Sie brauchen einen eigenen Plan, weil sie bei verkürzten Fristen immer wieder Druck erzeugen.
Was Service Owner jetzt prüfen sollten
- Gibt es eine vollständige Liste aller öffentlich relevanten Zertifikate und ihrer Services?
- Ist für jedes Zertifikat ein fachlicher und technischer Owner sichtbar?
- Welche Erneuerungen laufen automatisch und welche enthalten noch manuelle Schritte?
- Wer besitzt DNS- oder Validierungswege, die für die Erneuerung nötig sind?
- Wird nach jeder Erneuerung geprüft, ob der Dienst wirklich mit dem neuen Zertifikat antwortet?
- Gibt es Tickets, Eskalationen und Reporting für Zertifikate, die in den kritischen Bereich laufen?
Fazit
Die kürzere Gnadenfrist für Zertifikate ist kein Randthema für Kryptospezialisten. Sie zwingt IT-Organisationen, einen oft unterschätzten Betriebsprozess zu professionalisieren. Wer Zertifikate als Serviceabhängigkeit behandelt, gewinnt Transparenz, vermeidet unnötige Ausfälle und kann Erneuerungen in ruhige Routinen verwandeln. Wer weiter auf Kalender, Einzelwissen und manuelle Nacharbeit setzt, baut sich eine Störung mit Ansage.
