Zertifikatsablauf vs. Zertifikatswiderruf: Wesentliche Unterschiede und warum beides für die PKI relevant ist.

Ein außer Betrieb genommener Server verwendet noch immer ein altes TLS- Zertifikat . Ein Mitarbeiter, der das Unternehmen vor drei Monaten verlassen hat, besitzt noch immer ein gültiges Client-Zertifikat, da dieses nie widerrufen wurde. Möglicherweise wurde ein privater Schlüssel während einer Cloud-Migration offengelegt, doch das zugehörige Zertifikat zeigt weiterhin den Status „noch nicht abgelaufen“ an. Dies sind typische Fehler im Umgang von Unternehmen mit der Gültigkeit von Zertifikaten, die alle auf eine gemeinsame Ursache zurückzuführen sind: Ablauf und Widerruf werden fälschlicherweise gleichgesetzt.

Ablauf und Widerruf von Zertifikaten sind unterschiedliche Mechanismen, die in RFC 5280 separat definiert sind und im X.509-Vertrauensmodell verschiedenen Zwecken dienen. Der Ablauf eines Zertifikats ist ein geplantes Ereignis, das bei der Ausstellung im Zertifikat festgelegt wird. Der Widerruf eines Zertifikats ist eine bewusste Handlung der ausstellenden Zertifizierungsstelle (CA), die durch eine bestimmte Bedingung ausgelöst wird, die das Zertifikat vor seinem geplanten Ablaufdatum als nicht vertrauenswürdig einstuft.

Die Vermischung der beiden führt zu echten Lücken: Organisationen, die Erneuerungskalender sorgfältig verwalten, aber keine kohärente Widerrufsrichtlinie haben, oder Teams, die Zertifikate nach einer wichtigen Kompromittierung widerrufen, aber keinen Einblick haben, auf welchen Endpunkten sie noch ausgestellt sind.

Die Folgen sind nicht abstrakt. Am 3. Februar 2020 war Microsoft Teams fast drei Stunden lang offline, nachdem ein Authentifizierungszertifikat ohne Verlängerung abgelaufen war. Microsofts eigener Statusbeitrag bestätigte die Ursache: Ein Authentifizierungszertifikat war abgelaufen, was zu Problemen bei der Nutzung des Dienstes führte. Am 19. August 2020 waren Spotify-Nutzer etwa eine Stunde lang nicht erreichbar, da ein Wildcard-TLS-Zertifikat ablief und der Streaming-Dienst dadurch offline ging. Beide Vorfälle wären vermeidbar gewesen. Für keinen der beiden war ein ausgeklügelter Angriff nötig. Es reichte aus, dass niemand das Ablaufdatum im Auge behielt. Die DigiCert Trust Pulse Survey (Juli 2025) ergab, dass 45 Prozent der Unternehmen im Vorjahr zertifikatsbedingte Ausfallzeiten verzeichneten. Dies bestätigt, dass diese beiden Vorfälle keine Ausnahmen darstellen, sondern beispielhaft für eine weit verbreitete Sicherheitslücke sind.

Dieser Leitfaden erläutert die Bedeutung der einzelnen Mechanismen, ihre Unterschiede und die Anforderungen an einen funktionsfähigen Zertifikatslebenszyklus in Bezug auf beide.

Kurzantwort: Was ist der Unterschied zwischen Zertifikatsablauf und Zertifikatswiderruf?

Der Ablauf eines Zertifikats ist eine passive, planmäßige Grenze, die bei der Ausstellung im X.509-Feld „notAfter“ kodiert wird. Vertrauende Parteien weisen abgelaufene Zertifikate automatisch anhand der Systemuhr zurück; hierfür ist keine Infrastruktur erforderlich. Der Zertifikatswiderruf hingegen ist eine aktive Erklärung der Zertifizierungsstelle (CA), dass ein Zertifikat vor dem Ablaufdatum „notAfter“ nicht vertrauenswürdig ist. Diese Erklärung wird über CRLs (RFC 5280) oder OCSP (RFC 6960) kommuniziert. Beide Verfahren sind erforderlich. Keines allein ist ausreichend.

Wichtige Erkenntnisse

• Der Ablauf von Zertifikaten erfolgt passiv und infrastrukturunabhängig: Vertrauende Parteien lehnen abgelaufene Zertifikate lediglich anhand der Systemuhr und des Felds „notAfter“ aus RFC 5280 ab. Es sind keine Netzwerkaufrufe, keine Abhängigkeit von einer Zertifizierungsstelle und keine Aktualitätsprüfung erforderlich. Ein Ausfall aufgrund von Infrastrukturausfällen ist ausgeschlossen, da keine Infrastruktur vorhanden ist.
• Die Zertifikatssperrung ist ein aktiver und infrastrukturabhängiger Prozess: Die Zertifizierungsstelle muss die Sperrung protokollieren, eine Sperrliste (CRL) veröffentlichen oder auf OCSP-Anfragen antworten, und die vertrauenden Parteien müssen die Sperrung überprüfen. Ist der CRL-Verteilungspunkt nicht erreichbar oder tritt beim OCSP-Responder ein Timeout auf, erreicht die Sperrung möglicherweise nicht die Systeme, die darauf reagieren müssen.
• Die beiden Mechanismen beheben unterschiedliche Fehlerszenarien. Die Ablaufprüfung klärt, ob ein Zertifikat sein planmäßiges Ende erreicht hat. Die Widerrufsprüfung klärt, ob sich während der Gültigkeitsdauer des Zertifikats etwas geändert hat, das es unzuverlässig macht. Ein Schlüssel, der am zehnten Tag der Gültigkeitsdauer eines einjährigen Zertifikats kompromittiert wird, hinterlässt 355 Tage scheinbar gültigen Vertrauens, das nur durch einen Widerruf aufgehoben werden kann.
• RFC 5280 definiert zehn Widerrufsgründe (Werte 0–10, wobei Wert 7 nicht verwendet wird). Der Grundcode „keyCompromise“ (1) löst das 24-stündige Widerrufsfenster gemäß den CA/Browser Forum Baseline Requirements für öffentlich vertrauenswürdige TLS-Zertifikate aus. Der Grundcode „certificateHold“ (6) wird häufig fälschlicherweise als Ersatz für einen endgültigen Widerruf bei Schlüsselkompromittierung verwendet; dies ist jedoch genau falsch und führt dazu, dass ein potenziell kompromittiertes Zertifikat wiederhergestellt werden kann.
• Der CA/Browser Forum-Abstimmungsantrag SC-081v3 (angenommen am 11. April 2025, 29 Ja-Stimmen, 0 Nein-Stimmen, 5 Enthaltungen) sieht eine schrittweise Verlängerung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage (März 2026), 100 Tage (März 2027) und 47 Tage (März 2029) vor. Kürzere Gültigkeitsdauern verringern das Risiko eines unbemerkten Sicherheitsvorfalls. Diese Regelung gilt nicht für private PKI-, Codesignierungs- oder IoT-Gerätezertifikate, die weiterhin mehrjährige Gültigkeitsdauern haben und eine funktionierende Widerrufsinfrastruktur erfordern.

Für wen ist der Ablauf und die Widerrufung von Zertifikaten relevant?

Ablauf und Widerruf von Zertifikaten sind operative PKI-Themen, doch Fehler in diesen Bereichen haben unternehmensweite Folgen. Jedes der unten aufgeführten Teams muss daher beide Mechanismen und die entsprechenden Maßnahmen verstehen.

Funktion / Rolle (Role) *	Warum es wichtig ist	Aktionselement
PKI-Administratoren	Sie sind für den technischen Betrieb beider Mechanismen verantwortlich: Durchführung der Zertifikatserkennung, um alle relevanten Zertifikate zu finden, Überwachung der Ablaufdaten mit automatisierten Erneuerungsworkflows, Durchführung des Widerrufs bei der Zertifizierungsstelle (CA) bei Bedarf, Pflege der CRL-Veröffentlichungspläne und Validierung der Verfügbarkeit von CRL-Verteilungspunkten und OCSP-Respondern aus allen relevanten Netzwerksegmenten.	Prüfen Sie alle aktiven CRL-Verteilungspunkte und OCSP-Responder auf Erreichbarkeit aus jedem Netzwerksegment, in dem ausgestellte Zertifikate validiert werden; bestätigen Sie, dass die CRL-Veröffentlichungspläne gültige CRLs mit ausreichender Überlappung vor Ablauf der vorherigen CRL erzeugen; verbinden Sie alle Zertifikatsbestände mit CertSecure Manager zur kontinuierlichen Ablaufüberwachung und automatisierten Verlängerung
Sicherheitsarchitekten	Sie sind verantwortlich für die Gestaltung der Widerrufsrichtlinie: Sie definieren, welche Ereignisse einen Widerruf auslösen (Schlüsselkompromittierung, Ausscheiden eines Mitarbeiters, Systemstilllegung, Fehlausstellung), welcher Widerrufsstatus für jeden Ereignistyp angemessen ist (dauerhaft widerrufen vs. Zertifikatshaltung), die maximal zulässige Zeitspanne zwischen einem auslösenden Ereignis und dem abgeschlossenen Widerruf sowie die erforderlichen Gültigkeitsdauern für jeden Zertifikatstyp im Verhältnis zum jeweiligen Vertrauenslebenszyklus.	Erstellen Sie eine formale Widerrufsrichtlinie, die jedes Auslöseereignis einem Widerrufsgrund, einem Inhaber und einer Reaktionszeitanforderung zuordnet; beziehen Sie private PKI-, Codesignatur- und IoT-Gerätezertifikate in den Geltungsbereich der Widerrufsrichtlinie ein, nicht nur öffentlich vertrauenswürdige TLS-Zertifikate; beziehen Sie das kryptografische Inventar aller CA-Quellen in den Geltungsbereich der Widerrufsverwaltung ein. CBOM Secure
Plattform- und Cloud-Teams	Sie sind selbst dafür verantwortlich, dass CRL-Verteilungspunkte und OCSP-Responder von Cloud-Workloads, Containern und Hybridumgebungen aus erreichbar sind. Eine CRL, die von lokalen Umgebungen aus zugänglich ist, aber von einer Cloud-Netzwerksicherheitsgruppe blockiert wird, führt zu stillen Widerrufsfehlern für Cloud-Dienste. In zertifikatsintensiven Umgebungen (Kubernetes, Service Mesh, API-Gateways) muss die Widerrufsprüfung konfiguriert und getestet sein.	Testen Sie die Erreichbarkeit von CRL und OCSP aus allen Cloud- und Containerumgebungen im Rahmen der Infrastructure-as-Code-Validierung; integrieren Sie die Überwachung des Zertifikatsablaufs in die Plattform-Observability-Stacks; stellen Sie sicher, dass Service-Mesh- und API-Gateway-Konfigurationen die Zertifikatsvalidierung einschließlich der Prüfung auf Zertifikatssperrung und nicht nur auf Ablaufdatum erzwingen.
Compliance-Teams	Es muss nachgewiesen werden, dass eine Widerrufsrichtlinie existiert, eingehalten wird und die zugehörige Infrastruktur (CRL-Verteilung, OCSP) getestet und betriebsbereit ist. Die NIST SP 800-53 Rev. 5-Kontrollen SC-12 und SC-17 decken die Verwaltung kryptografischer Schlüssel und die Steuerung des PKI-Zertifikatlebenszyklus ab. Prüfer fordern zunehmend Nachweise dafür, dass die Widerrufsinfrastruktur erreichbar ist und Widerrufsvorgänge innerhalb des dokumentierten Richtlinienzeitraums abgeschlossen werden.	Fügen Sie die vierteljährlichen Ergebnisse der CRL- und OCSP-Erreichbarkeitstests den Nachweisen zur Konformität bei; dokumentieren Sie die Widerrufsrichtlinie und stellen Sie sicher, dass alle Auslöserereignisse einen benannten Verantwortlichen und eine Reaktionszeitvorgabe haben; stellen Sie sicher, dass die CA-Audit-Logs, die Widerrufsereignisse erfassen, für den erforderlichen Zeitraum aufbewahrt und zur Überwachung an das SIEM-System weitergeleitet werden.
CISOS	Der Ablauf von Zertifikaten zählte zu den drei größten Sorgen von CISOs (DigiCert Trust Pulse Survey, Juli 2025, 56.6 Prozent). Widerrufsfehler stellen die weniger sichtbare Seite desselben Problems dar: Ein schwerwiegender Sicherheitsvorfall, bei dem das Zertifikat zwar von der Zertifizierungsstelle widerrufen wird, dessen Widerruf aber von den vertrauenden Parteien nicht bestätigt werden kann, weil der CRL-Verteilungspunkt nicht erreichbar ist, vermittelt fälschlicherweise die Gewissheit, dass die Gefährdung eingedämmt wurde.	Ein formelles Zertifikatslebenszyklusmanagementprogramm, das sowohl die Ablaufüberwachung als auch die Widerrufsrichtlinie als finanzierte, kontinuierliche Aktivitäten umfasst, ist erforderlich; jährliche Tests der Widerrufsinfrastruktur als PKI-Integritätskontrolle sind vorzuschreiben; evaluieren PKI als Service für Organisationen, deren interne PKI-Infrastruktur die Aufrechterhaltung der Widerrufsinfrastruktur erschwert.

Ablauf vs. Widerruf: Entscheidungsmatrix nach Szenario

Anhand dieser Matrix lässt sich ermitteln, welcher Mechanismus für welches Szenario geeignet ist, welche Auswirkungen er auf die Sicherheit hat, wie hoch der erforderliche operative Aufwand ist, wie gut er sich in automatisierte Arbeitsabläufe integrieren lässt und wer für die Reaktion verantwortlich ist.

Szenario	Mechanismus	Auswirkungen auf die Sicherheit	Operativer Aufwand	Automatisierungsanpassung	Empfohlener Eigentümer
Das Zertifikat erreicht normalerweise sein Nicht-Nach-Datum	Ablauf (passiv)	Es kommt zu einer Serviceunterbrechung, wenn die Verlängerung nicht vor Ablauf der Gültigkeit abgeschlossen wurde; es besteht kein Sicherheitsvorfall, wenn das Zertifikat gültig war.	Niedrig mit Automatisierung; hoch ohne sie	Hervorragend: CLM-Plattformen automatisieren Verlängerungsprozesse mit ablaufbasierten Auslösern.	PKI-Administrator
Privater Schlüssel bestätigt oder Verdacht auf Kompromittierung	Widerruf (dauerhaft, Grundcode 1: Schlüsselkompromittierung)	Wichtig: Jedes an den kompromittierten Schlüssel gebundene Zertifikat muss unverzüglich widerrufen werden; die CA/Browser Forum Baseline Requirements fordern einen Widerruf innerhalb von 24 Stunden für öffentlich vertrauenswürdige TLS-Zertifikate.	Hoch: Erfordert die schnelle Identifizierung aller an den Schlüssel gebundenen Zertifikate, den Widerruf bei der Zertifizierungsstelle und die Bestätigung der CRL/OCSP-Weitergabe.	Mittel: CLM kann alle an einen Schlüssel gebundenen Zertifikate identifizieren und eine Massensperrung auslösen; der Zeitpunkt der CRL-Weitergabe liegt außerhalb der Kontrolle von CLM.	PKI-Administrator + Sicherheitsteam (gemeinsame Reaktion)
Mitarbeiterabgang mit gültigen Kundenzertifikaten	Widerruf (dauerhaft, Grund für Änderung der Zugehörigkeit: Code 3 oder Grund für Betriebseinstellung: Code 5)	Hoch: Ein aktives Kundenzertifikat für einen ausgeschiedenen Mitarbeiter bleibt bis zu seinem Ablauf oder seiner Widerrufung zur Authentifizierung nutzbar; die Gültigkeitsdauer hängt von der verbleibenden Gültigkeitsdauer des Zertifikats ab.	Mittel: Erfordert die Ermittlung aller aktiven, mit der Identität verknüpften Zertifikate, die Abstimmung mit der Personalabteilung beim Offboarding und den Widerruf bei der Zertifizierungsstelle.	Gut: CLM-Plattformen mit Integration von Identitätssystemen können den Widerruf im Rahmen von HR-Offboarding-Prozessen auslösen.	PKI-Administrator + HR/Identitätsteam
System oder Dienst außer Betrieb genommen	Widerruf (dauerhaft, Betriebseinstellungsgrundcode 5)	Mittel: Ein technisch noch gültiges Zertifikat eines nicht erreichbaren Systems kann verwendet werden, um den außer Betrieb genommenen Dienst zu imitieren, wenn der private Schlüssel von einem anderen System aus zugänglich ist.	Niedrig bis mittel: Deaktivierungsprozesse sollten einen Widerrufsschritt beinhalten; wenn das System nicht erreichbar ist, kann die Zertifizierungsstelle den Widerruf ohne Beteiligung des Endpunkts durchführen.	Gut: Die CLM-Automatisierung kann den Widerruf als Schritt in den Systemstilllegungs-Runbooks beinhalten.	PKI-Administrator + Plattformteam
Das Zertifikat wurde fälschlicherweise ausgestellt oder enthält falsche Informationen	Widerruf (dauerhaft, nicht näher spezifizierter Grundcode 0 oder ersetzter Grundcode 4)	Hoch: Ein Zertifikat mit fehlerhaften Informationen im Subjekt oder in den SANs bietet den vertrauenden Parteien eine falsche Identitätssicherheit.	Mittel: Erfordert die Identifizierung des fehlerhaft ausgestellten Zertifikats, dessen Widerruf und die Ausstellung eines korrekten Ersatzzertifikats.	Gut: Die CLM-Erkennung deckt fehlerhaft ausgestellte Zertifikate auf; Widerruf und Neuausstellung können über die CLM-Schnittstelle ausgelöst werden.	PKI-Administrator
Das als gestohlen gemeldete Gerät wurde später unbeschädigt wiedergefunden, der Schlüssel blieb nachweislich unbenutzt.	CertificateHold (Grundcode 6), reversibel, falls als sicher bestätigt.	Während der Sperrfrist wird der Sperrstatus angezeigt: Vertrauende Parteien, die CRL/OCSP prüfen, sehen den Sperrstatus; wenn die Widerrufsprüfung unvollständig ist, kann das Zertifikat während der Sperrfrist dennoch akzeptiert werden.	Mittel: Erfordert eine Sperrung, die Durchführung einer Geräteuntersuchung und die Aufhebung der Sperre oder die Eskalation zu einem dauerhaften Entzug basierend auf den Ergebnissen.	Mittel: CLM kann Haltegriffe anlegen und aufheben; das Risiko des Missbrauchs von Haltegriffen erfordert jedoch menschliches Urteilsvermögen bei der Eskalation.	PKI-Administrator + Sicherheitsteam (gemeinsame Entscheidung)
Zertifikat für IoT-Geräte mit mehrjähriger Gültigkeit und ohne Verlängerungsmöglichkeit	Nur Ablaufdatum (ein Widerruf muss ebenfalls vorliegen, aber für eine Verlängerung kann physischer Zugang erforderlich sein)	Hohes Risiko bei Kompromittierung: Die gesamte verbleibende Gültigkeitsdauer wird offengelegt; der Widerruf ist die einzige Kontrollmöglichkeit; ohne erreichbare CRL/OCSP aus dem Netzwerk des Geräts kann der Widerruf nicht validiert werden.	Hoch: Geräte-Firmware und Netzwerkarchitektur müssen das Abrufen von CRLs oder die OCSP-Prüfung aus der Betriebsumgebung des Geräts unterstützen.	Ungünstig für die Verlängerung; CLM kann zwar überwachen und Alarme auslösen, aber die Verlängerung erfordert möglicherweise einen separaten Prozess.	PKI-Admin + Betriebs-/OT-Team

Was das Ablaufdatum eines Zertifikats bedeutet

Jedes X.509-Zertifikat enthält ein Gültigkeitsfeld mit zwei Unterfeldern: „notBefore“ und „notAfter“. Diese werden bei der Ausstellung festgelegt und sind im Zertifikat selbst eingebettet. Das Feld „notBefore“ markiert den Zeitpunkt, ab dem das Zertifikat gültig wird. Das Feld „notAfter“ markiert den Zeitpunkt, ab dem es nicht mehr akzeptiert wird. Sobald die Systemuhr den im Zertifikat festgelegten „notAfter“-Zeitstempel überschreitet, lehnt jede vertrauende Partei das Zertifikat automatisch ab – ohne Signal der Zertifizierungsstelle, ohne Prüfung externer Dienste und ohne menschliches Eingreifen.

Diese automatische Ablehnung ist der Kernvorteil des Ablaufs. Sie stellt eine harte, lokale und passive Vertrauensgrenze dar. Ein TLS-Client prüft die Systemuhr anhand des Felds „notAfter“ und trifft seine Entscheidung völlig selbstständig. Es gibt keinen Netzwerkaufruf, keine Abhängigkeit von einem laufenden Server und keine Berücksichtigung der Aktualität. Der Mechanismus kann aufgrund von Infrastrukturausfällen nicht versagen, da er keine Infrastruktur benötigt.

Gemäß RFC 5280 werden diese Datumsangaben für Daten bis einschließlich 2049 als UTCTime und für Daten ab 2050 als GeneralizedTime kodiert. Für Zertifikate ohne definiertes Ablaufdatum, wie beispielsweise bestimmte Geräteidentitätszertifikate, legt RFC 5280 den GeneralizedTime-Wert 99991231235959Z fest. Diese Zertifikate sind für den Betrieb praktisch unbegrenzt gültig. Sofern ihre Vertrauenswürdigkeit nicht aktiv aufgehoben wird, bleiben sie weit über den realistischen Lebenszyklus eines Systems oder einer Bereitstellung hinaus gültig.

Die Einschränkung des Ablaufs liegt genau in seiner Passivität. Er reagiert nicht auf Ereignisse. Wird beispielsweise am zehnten Tag der Gültigkeitsdauer eines einjährigen Zertifikats der private Schlüssel gestohlen, bleibt das Zertifikat aus Sicht des Vertrauenden für die verbleibenden 355 Tage gültig. Das Feld „notAfter“ gibt keinerlei Hinweis darauf, dass das zugrunde liegende Vertrauen bereits gebrochen ist. Der Ablauf regelt das geplante Ende der Gültigkeitsdauer. Er verfügt über keinen Mechanismus, um einen ungeplanten Vertrauensverlust zu behandeln.

Was der Entzug eines Zertifikats bedeutet

Die Widerrufung eines Zertifikats ist die Erklärung der Zertifizierungsstelle (CA), dass ein Zertifikat vor dem Ablaufdatum nicht mehr vertrauenswürdig ist. Es handelt sich um einen aktiven, bewussten Akt. Die CA kennzeichnet das Zertifikat als ungültig, und diese Information wird anschließend den vertrauenden Parteien über einen von zwei Mechanismen mitgeteilt: eine Zertifikatssperrliste (CRL) oder das Online Certificate Status Protocol (OCSP).

RFC 5280 definiert zwei Widerrufszustände. Der erste ist „widerrufen“, was dauerhaft und unumkehrbar ist. Ein widerrufenes Zertifikat bleibt widerrufen. Der zweite ist „certificateHold“, eine vorübergehende Sperrung, die aufgehoben werden kann. Hold wird in der Praxis selten verwendet und bietet nur begrenzten Sicherheitsnutzen, da der Vertrauende nicht wissen kann, wann oder ob die Sperrung aufgehoben wird.

RFC 5280 definiert zehn Gründe, die eine Zertifizierungsstelle einem Widerrufseintrag zuordnen kann: nicht spezifiziert (0), Schlüsselkompromittierung (1), Kompromittierung einer Zertifizierungsstelle (2), Zugehörigkeit geändert (3), ersetzt (4), Betriebseinstellung (5), Zertifikat gesperrt (6), aus der Sperrliste entfernt (8), Berechtigung entzogen (9) und Kompromittierung einer Zertifizierungsstelle (10). Der Wert 7 wird nicht verwendet. Diese Gründe sind nicht nur administrative Bezeichnungen, sondern haben eine operative Bedeutung.

Der Code „keyCompromise“ signalisiert, dass der private Schlüssel offengelegt wurde. Gemäß den CA/Browser Forum Baseline Requirements muss ein öffentlich vertrauenswürdiges TLS-Zertifikat innerhalb von 24 Stunden nach bestätigter Schlüsselkompromittierung widerrufen werden. Die Codes „affiliationChanged“ oder „superseded“ greifen, wenn sich die Identität oder Rolle eines Zertifikatsinhabers geändert hat, nicht weil der Schlüssel kompromittiert wurde, sondern weil die Bindung nicht mehr korrekt ist.

Der Widerruf ist der Mechanismus, der auf bestimmte Ereignisse reagiert. In der Praxis ist es wichtig zu verstehen, wann welcher Widerrufsstatus anzuwenden ist. Der endgültige Widerruf, der Status „widerrufen“, erfolgt immer dann, wenn der zugrunde liegende Grund eindeutig und unumkehrbar ist. Ein als kompromittiert bestätigter privater Schlüssel muss endgültig widerrufen werden: Es gibt kein Szenario, in dem dieser Schlüssel wieder vertrauenswürdig wird. Dasselbe gilt, wenn ein Mitarbeiter das Unternehmen verlässt, ein System außer Betrieb genommen wird oder ein Zertifikat fälschlicherweise ausgestellt wurde. In all diesen Fällen existiert die Identität, die das Zertifikat bindet, nicht mehr, und die Wiederherstellung des Zertifikats hätte keinen legitimen Zweck.

Der Status „certificateHold“ deckt einen engeren und wirklich vorübergehenden Anwendungsfall ab. Beispielsweise ein Gerät, das als gestohlen gemeldet, später aber unbeschädigt wiedergefunden wurde und dessen privater Schlüssel nachweislich nicht verwendet wurde. Oder ein Zertifikat, das an ein Dienstkonto gebunden ist, das auf ein neues System migriert wird, wo der Betrieb für einen definierten Zeitraum pausiert wird und dasselbe Zertifikat nach Abschluss der Migration wieder verwendet wird. „Hold“ ist die richtige Wahl, wenn der besorgniserregende Zustand reversibel ist und die Organisation erwartet, das Zertifikat wiederherzustellen.

Die Verwendung des Status „Halten“ anstelle des Status „Widerrufen“ ist die falsche Wahl, wenn der Zustand sicherheitsrelevant und dauerhaft ist, beispielsweise weil ein Widerruf als drastisch empfunden wird oder eine Neuausstellung umständlich ist. Dieser Missbrauch des Status „Halten“ führt dazu, dass ein potenziell kompromittiertes Zertifikat in einem wiederherstellbaren Zustand verbleibt – genau das Risiko, das durch einen Widerruf geschlossen werden soll.

Während die Ablaufzeit das planmäßige Ende einer Vertrauensbeziehung regelt, deckt der Widerruf alle Szenarien ab, in denen die Vertrauensbeziehung vor dem planmäßigen Ende endet.

Wie der Widerrufsstatus mitgeteilt wird

Die Aufhebung eines Zertifikats bei der Zertifizierungsstelle hat für die vertrauenden Parteien keine Auswirkungen, solange dieser Status nicht mitgeteilt und überprüft wird. Hierfür gibt es zwei Mechanismen.

Zertifikatssperrlisten (CRLs), definiert in RFC 5280 Abschnitt 5, sind von Zertifizierungsstellen signierte Dateien, die die Seriennummern von Zertifikaten enthalten, die von der ausstellenden Zertifizierungsstelle widerrufen wurden. Eine vertrauende Partei lädt die CRL herunter, prüft, ob die Seriennummer des Zertifikats darin enthalten ist, und verfährt entsprechend. CRL-Einträge werden nicht automatisch entfernt, wenn ein Zertifikat abläuft. Gemäß RFC 5280 Abschnitt 3.3 muss ein Eintrag so lange in der CRL verbleiben, bis er in mindestens einer regelmäßig nach dem Ablaufdatum des Zertifikats veröffentlichten CRL erscheint. Dies stellt sicher, dass ein kurz vor Ablauf widerrufenes Zertifikat nicht stillschweigend aus der Liste entfernt wird, bevor Clients die Möglichkeit hatten, die aktualisierte CRL zu erhalten.

CRLs weisen eine Verzögerung bei der Veröffentlichung auf. Eine Zertifizierungsstelle (CA) veröffentlicht regelmäßig neue CRLs, typischerweise alle 24 bis 72 Stunden (bei vielen Unternehmens-CAs). Ein Zertifikat, das unmittelbar nach der Veröffentlichung einer CRL widerrufen wird, ist für vertrauende Parteien erst sichtbar, wenn die nächste CRL veröffentlicht und abgerufen wurde. In diesem Zeitraum kann ein widerrufenes Zertifikat die CRL-Prüfungen noch bestehen. Da immer mehr Zertifikate widerrufen werden, wächst die Anzahl der CRLs mit der Zeit, was den Downloadaufwand für Clients erhöht.

OCSP (Online Certificate Status Protocol), definiert in RFC 6960, löst das Skalierungsproblem durch die Prüfung des Zertifikatssperrstatus pro Zertifikat und auf Anfrage. Ein Client sendet eine Anfrage mit der Seriennummer des Zertifikats an einen OCSP-Responder. Dieser gibt einen von drei Status zurück: gültig, gesperrt oder unbekannt.

„Gültig“ bedeutet, dass für die betreffende Seriennummer innerhalb des Gültigkeitszeitraums kein Widerrufseintrag vorliegt. Dies bestätigt jedoch nicht die rechtmäßige Ausstellung des Zertifikats. „Widerrufen“ bedeutet, dass das Zertifikat widerrufen wurde, üblicherweise mit Angabe eines Grundes und eines Zeitstempels. „Unbekannt“ bedeutet, dass der Antwortgeber den Status des Zertifikats nicht ermitteln kann, was darauf hindeuten kann, dass das Zertifikat nicht von der betreffenden Zertifizierungsstelle ausgestellt wurde.

In modernen TLS-Implementierungen ermöglicht OCSP Stapling einem Server, eine OCSP-Antwort zu empfangen, zwischenzuspeichern und direkt an den TLS-Handshake anzuhängen . Dadurch wird die Notwendigkeit für Clients, den OCSP-Responder selbst abzufragen, reduziert oder sogar ganz vermieden. Dies verbessert die Performance und mindert die Bedenken hinsichtlich des Datenschutzes, die entstehen, wenn Clients ihre Zertifikatsvalidierungsaktivitäten der Zertifizierungsstelle offenlegen. OCSP Stapling ist in RFC 6066 über die TLS-Statusanforderungserweiterung definiert und wird sowohl von TLS 1.2 als auch von TLS 1.3 unterstützt.

Der Kernunterschied in der Praxis

Ablauf und Widerruf sind nicht redundant. Sie decken unterschiedliche Fehlermodi ab.

• Die Ablaufprüfung beantwortet die Frage: „Hat dieses Zertifikat sein geplantes Ablaufdatum erreicht?“ Sie überwacht diese Grenze automatisch und ohne zusätzliche Infrastruktur, basierend allein auf der Systemuhr und dem Feld „notAfter“. Sie arbeitet zuverlässig und passiv. Sie reagiert nicht auf Ereignisse während der Gültigkeitsdauer des Zertifikats.
• Die Frage nach dem Widerruf lautet: „Hat sich seit der Ausstellung dieses Zertifikats etwas geändert, das es unzuverlässig macht?“ Dafür sind aktive Maßnahmen der Zertifizierungsstelle, eine Kommunikationsinfrastruktur (CRL oder OCSP) und vertrauende Parteien erforderlich, die dies überprüfen. Es handelt sich nicht um einen passiven Vorgang. Der Widerruf kann fehlschlagen, wenn die Infrastruktur ausgefallen, veraltet oder nicht erreichbar ist.

Ein seit einer Woche abgelaufenes Zertifikat ist einfach ungültig. Jeder Client lehnt es sofort und ohne weitere Prüfung ab. Ein vor zwei Tagen widerrufenes, aber noch nicht abgelaufenes Zertifikat erfordert hingegen, dass die vertrauende Partei die CRL oder OCSP prüft, eine Widerrufsbestätigung erhält und entsprechend reagiert. Schlägt diese Prüfung fehl oder wird sie übersprungen, kann das Zertifikat dennoch akzeptiert werden. Diese Asymmetrie verdeutlicht die Bedeutung einer qualitativ hochwertigen Infrastruktur für den Zertifikatswiderruf. Der Mechanismus funktioniert nur, wenn die ihn unterstützende Infrastruktur leistungsfähig ist.

Wo jedes einzelne System versagt

Die Gültigkeitsdauer eines Zertifikats ist zu lang, wenn sie im Verhältnis zum damit verbundenen Vertrauensverhältnis zu lang ist. Ein dreijähriges Zertifikat, das einem Mitarbeiter ausgestellt wurde, der das Unternehmen in 90 Tagen verlässt, hat eine Restgültigkeit von über 1,000 Tagen und stellt somit keine legitime Identitätsbindung mehr dar. Das Zertifikat wurde nie widerrufen und wird daher weiterhin die Ablaufprüfung bestehen. Wenn der Mitarbeiter weiterhin Zugriff auf den privaten Schlüssel hat und das Unternehmen keine Widerrufsprüfung durchführt, bleibt das Zertifikat fast drei weitere Jahre nutzbar.

Auch bei Zertifikaten mit unbegrenzter Gültigkeit ist der Ablaufschutz völlig unzureichend. Ein Gerätezertifikat mit dem GeneralizedTime-Wert 99991231235959Z bietet keinerlei Ablaufschutz. Wird das Gerät außer Betrieb genommen, der Schlüssel kompromittiert oder das Zertifikat fehlerhaft ausgestellt, ist der Widerruf die einzige Kontrollmöglichkeit. Es gibt kein festgelegtes Ablaufdatum.

Die Widerrufung verliert ihre Wirksamkeit, wenn die zugehörige Infrastruktur nicht gewartet wird. Eine Zertifizierungsstelle (CA), die ein Zertifikat technisch widerrufen hat, deren CRL-Verteilungspunkt-URL jedoch vom relevanten Netzwerksegment aus nicht erreichbar ist oder deren OCSP-Responder unter Last einen Timeout verursacht, hat einen Widerruf ausgesprochen, auf den kein vertrauender Teilnehmer reagieren kann. Der Widerruf ist zwar in der Datenbank der CA vorhanden, erreicht aber nicht die Systeme, die ihn benötigen.

Der Widerruf verliert als Ausgleichsmaßnahme für kurzlebige öffentliche Zertifikate an Bedeutung, wenn die Überprüfung im großen Maßstab unzuverlässig ist. Dies ist einer der Gründe für die Abstimmung SC-081v3 des CA/Browser Forums, die am 11. April 2025 mit 29 Ja-Stimmen, keiner Nein-Stimme und fünf Enthaltungen angenommen wurde. Die Abstimmung reduziert die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate von 398 Tagen auf 200 Tage im März 2026, dann auf 100 Tage im März 2027 und schließlich auf 47 Tage im März 2029.

Bei einer maximalen Gültigkeitsdauer von 47 Tagen ist das Zeitfenster für eine unentdeckte Schlüsselkompromittierung begrenzt, unabhängig davon, ob die Widerrufsprüfung erfolgreich ist oder fehlschlägt. Diese Logik gilt nicht für private PKI- , Codesignierungs- oder IoT-Gerätezertifikate, die oft mehrjährige Gültigkeitsdauern aufweisen und bei denen eine kurze Gültigkeitsdauer keine funktionierende Widerrufsinfrastruktur ersetzen kann.

Warum beide zusammenarbeiten müssen

Keiner der beiden Mechanismen allein ist ausreichend. Ein Ablauf ohne Widerruf lässt ein Zeitfenster von potenziell Jahren offen, in dem ein kompromittiertes oder falsch ausgestelltes Zertifikat weiterhin gültig ist. Ein Widerruf ohne diszipliniertes Gültigkeitsmanagement legt die gesamte Vertrauensbasis auf eine Infrastruktur, die veralten, unerreichbar oder vernachlässigt werden kann.

Die beiden Mechanismen ergänzen sich. Das Ablaufdatum setzt eine feste Obergrenze für den Vertrauenszeitraum. Der Widerruf ermöglicht es, diesen Zeitraum bei Bedarf vorzeitig zu schließen. Eine Organisation, die beide Mechanismen effektiv verwaltet, weiß, wann jedes von ihr ausgestellte Zertifikat abläuft, unterhält eine Widerrufsinfrastruktur, die von den Systemen, die sie überprüfen müssen, tatsächlich erreicht werden kann, und verfügt über eine Richtlinie, die bestimmte Ereignisse wie Schlüsselkompromittierung, Mitarbeiterausscheiden oder Systemstilllegung einer Widerrufsaktion mit einem definierten Zeitrahmen zuordnet.

Insbesondere bei privaten PKIs bedeutet das Fehlen externer Kontrollen durch Browser-Root-Programme oder CA/B-Forum-Anforderungen, dass die Qualität der Ablaufverwaltung und der Widerrufsinfrastruktur vollständig von internen Designentscheidungen abhängt. Eine private CA-Hierarchie, die Zertifikate ohne erreichbare CDP- und AIA-Erweiterungen oder ohne OCSP-Responder ausstellt, verfügt unabhängig von ihrer Konfiguration über keinen effektiven Widerrufsmechanismus. Die Zertifikate scheinen zwar widerrufbar zu sein, sind es aber nicht. Für Organisationen, die ein vollständiges kryptografisches Inventar einschließlich privater PKI-Zertifikate aufbauen, bietet CBOM Secure die umgebungsübergreifende Erkennung von Maschinenidentitäten, die eine skalierbare Widerrufsverwaltung in hybriden und Multi-CA-Umgebungen ermöglicht.

Das Verständnis des Unterschieds zwischen Ablauf und Widerruf ist keine rein theoretische Übung. Es bildet die Grundlage dafür, zu wissen, was die PKI einer Organisation leisten kann und was nicht, wenn im Laufe des Lebenszyklus Probleme auftreten. Da die Einführung von Post-Quanten-Kryptographie nach der Veröffentlichung der NIST FIPS 203, 204 und 205 (13. August 2024) zunimmt, muss der Rahmen für die Verwaltung von Widerruf und Ablauf auch die privaten Zertifizierungsstellenhierarchien umfassen, die ML-DSA-basierte Zertifikate ausstellen. Die PQC-Readiness -Assessment-Services und das PQC Center of Excellence unterstützen Organisationen bei der Planung, wie sich Algorithmenübergänge auf die Gültigkeitsdauer von Zertifikaten und die Gestaltung der Widerrufsinfrastruktur auswirken.

Wie Verschlüsselungsberatung helfen kann

Die PKI-Bewertung von Encryption Consulting ist ein strukturierter Prozess, der Ihre gesamte PKI-Umgebung hinsichtlich Technik, Betrieb und Governance analysiert. Sie beginnt mit der Bedarfsanalyse: Dabei wird Ihre aktuelle PKI-Architektur in On-Premise-, Cloud- und Hybridumgebungen erfasst, um ein vollständiges Bild des Bestands, der Konfiguration und der Verbindungen zu erhalten.

Dies umfasst die Validierung der CA-Hierarchie, die Überprüfung der Zertifikatvorlagen, die Schlüsselverwaltungspraktiken und einen End-to-End-Test Ihrer Widerrufsinfrastruktur, bei dem überprüft wird, ob die CDP- und AIA-Erweiterungen in den ausgestellten Zertifikaten auf Responder und Verteilungspunkte verweisen, die von den Netzwerksegmenten, in denen die Zertifikate validiert werden, tatsächlich erreichbar sind.

Im Anschluss daran erfassen strukturierte Stakeholder-Workshops und Architektur-Mapping-Sitzungen die tatsächliche Betriebssituation hinter der Konfiguration. Diese Sitzungen decken Lücken auf, die die Dokumentation allein nicht sichtbar macht: PKI-Infrastrukturrichtlinien, die zwar existieren, aber nicht durchgesetzt werden, OCSP-Responder, die zwar technisch implementiert, aber unter Last nicht getestet wurden, und Zertifikate, die anhand von Vorlagen ausgestellt wurden, die nicht mehr den aktuellen Sicherheitsstandards entsprechen.

Das Ergebnis ist ein priorisierter Risiko- und Gap-Analysebericht. Die Ergebnisse sind nach Schweregrad geordnet und konkreten Abhilfemaßnahmen zugeordnet, sodass Ihr Team einen klaren Fahrplan anstelle einer allgemeinen Checkliste erhält.

CertSecure Manager

CertSecure Manager bildet die operative Ebene, die Ablaufverfolgung und Widerruf von Zertifikaten kontinuierlich miteinander verknüpft. Es verwaltet ein aktuelles Zertifikatsinventar über öffentliche Zertifizierungsstellen, private Zertifizierungsstellenhierarchien, HashiCorp Vault und Microsoft PKI-Umgebungen hinweg. Zu den wichtigsten Funktionen von CertSecure Manager gehören:

• Zentrale Zertifikatsverwaltung: Erkennt und inventarisiert automatisch Zertifikate in Cloud-, On-Premise- und Hybridumgebungen.
• Automatisiertes Lebenszyklusmanagement: Gewährleistet die Ausstellung, Verlängerung und den Widerruf von Zertifikaten mit minimalem menschlichen Eingriff.
• Richtliniendurchsetzungsmodul: Gewährleistet die Einhaltung der Unternehmenssicherheitsrichtlinien und Branchenstandards.
• Rollenbasierte Zugriffskontrolle (RBAC): Ermöglicht eine detaillierte Zugriffsverwaltung, um sicherzustellen, dass nur autorisierte Benutzer Zertifikate verwalten können.
• Integration mit führenden Zertifizierungsstellen und DevOps-Tools: Lässt sich nahtlos in öffentliche und private Zertifizierungsstellen sowie CI/CD-Pipelines integrieren.
• Echtzeitüberwachung und Warnmeldungen: Bietet Dashboards und Warnmeldungen für ablaufende oder falsch konfigurierte Zertifikate.
• Prüfung und Berichterstattung: Führt detaillierte Protokolle und Berichte zur Einhaltung der Vorschriften und für forensische Analysen.

Zusammen bieten diese Funktionen Ihrem Team die nötige Transparenz und Kontrolle, um den Ablauf und Widerruf von Zertifikaten nicht als reaktive Aufgaben, sondern als kontinuierlichen, nachvollziehbaren Prozess zu verwalten.

Fazit

Ablauf und Widerruf von Zertifikaten beheben unterschiedliche Fehlerszenarien an verschiedenen Punkten im Zertifikatslebenszyklus. Der Ablauf begrenzt die Gesamtdauer des Vertrauens und setzt diese Grenze automatisch durch. Der Widerruf greift ein, wenn das Vertrauen vor Ablauf der Gültigkeitsdauer verloren geht. Beide sind notwendig und funktionieren ohne eine entsprechende Infrastruktur nicht zuverlässig.

Da die Gültigkeitsdauer öffentlicher TLS-Zertifikate gemäß SC-081v3 verkürzt wird, verringert sich auch die Auswirkung von Widerrufsfehlern aufgrund der kürzeren Zertifikatslebensdauer. Für private PKI- , Codesignierungs- und Gerätezertifikate ändert sich diese Tatsache nicht.

Für Organisationen, die ihre aktuelle PKI-Strategie bewerten, Lücken in der Widerrufsinfrastruktur identifizieren oder ihre Praktiken im Zertifikatslebenszyklusmanagement verbessern möchten, bietet eine umfassende PKI-Bewertung und eine automatisierte Plattform für das Zertifikatslebenszyklusmanagement die nötige Transparenz und Kontrolle, um Zertifikate während ihres gesamten Lebenszyklus zu verwalten.

Organisationen, die den Widerruf von Zertifikaten in Umgebungen mit langer Gültigkeitsdauer als zweitrangig betrachten, gehen davon aus, dass sich in ihrer PKI- Infrastruktur bis zum Ablaufdatum nichts ändert. Das ist keine Sicherheitsarchitektur, sondern ein Kalender.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Unterschied zwischen Zertifikatsablauf und Zertifikatswiderruf?

Ablauf und Widerruf von Zertifikaten sind unterschiedliche Mechanismen, die in RFC 5280 separat definiert sind und verschiedene Fehlermodi adressieren. Der Ablauf erfolgt passiv: Er setzt automatisch eine feste, geplante Grenze mithilfe des Felds „notAfter“ und der Systemuhr durch, ohne dass eine Infrastruktur erforderlich ist. Der Widerruf hingegen ist aktiv: Er erfordert, dass die Zertifizierungsstelle (CA) ein Zertifikat vor dessen Ablaufdatum als nicht vertrauenswürdig einstuft und ist auf eine CRL- oder OCSP-Infrastruktur angewiesen, um diesen Status zu kommunizieren. Organisationen, die zwar ihre Erneuerungskalender sorgfältig verwalten, aber keine einheitliche Widerrufsrichtlinie haben, lösen damit nur die Hälfte des Problems im Zertifikatslebenszyklus.

Warum sind Zertifikatsablauf und -widerruf für PKI-Teams in Unternehmen relevant?

Am 3. Februar 2020 war Microsoft Teams fast drei Stunden lang offline, nachdem ein Authentifizierungszertifikat ohne Verlängerung abgelaufen war. Am 19. August 2020 kam es bei Spotify-Nutzern zu etwa einer Stunde Ausfallzeit, als ein Wildcard-TLS-Zertifikat ablief. Laut der DigiCert Trust Pulse Survey (Juli 2025) verzeichneten 45 Prozent der Unternehmen im Vorjahr Ausfallzeiten aufgrund von Zertifikatsproblemen. Diese Vorfälle sind die vorhersehbare Folge davon, dass der Ablauf von Zertifikaten als einzige Vertrauensgrenze betrachtet und der Widerruf als ergänzende Kontrollmaßnahme vernachlässigt wird.

Welche Risiken erhöhen sich, wenn der Ablauf und der Widerruf von Zertifikaten manuell verwaltet werden?

Die manuelle Verwaltung birgt vier Risikokategorien: verpasste Erneuerungen (manuelle Erneuerungskalender erfassen Zertifikate in nicht abgedeckten Umgebungen nicht); Verzögerungen bei der Widerrufung (eine wichtige Sicherheitslücke, die gemäß den CA/Browser Forum Baseline Requirements innerhalb von 24 Stunden ein Eingreifen erfordert, kann in großem Umfang nicht zuverlässig manuell behoben werden); unsichtbare Widerrufe (ein bei der Zertifizierungsstelle widerrufenes Zertifikat, dessen CRL-Verteilungspunkt jedoch vom relevanten Netzwerksegment aus nicht erreichbar ist, erreicht nie die Systeme, die darauf reagieren müssen); und verwaiste Anmeldeinformationen (wenn ein Mitarbeiter das Unternehmen verlässt oder ein System außer Betrieb genommen wird und kein Widerruf erfolgt, bleibt ein gültiges Zertifikat auf unbestimmte Zeit im Umlauf).

Welche Teams sollten für die Verwaltung des Ablaufs und des Widerrufs von Zertifikaten zuständig sein?

PKI-Administratoren sind für den technischen Betrieb verantwortlich: Erkennung, Ablaufüberwachung, Durchführung von Widerrufen, CRL-Veröffentlichung und Wartung des OCSP-Responders. Sicherheitsarchitekten verantworten die Richtliniengestaltung: welche Ereignisse einen Widerruf auslösen, welcher Widerrufsstatus gilt und die maximale Reaktionszeit. Compliance-Teams stellen die Audit-Nachweise sicher, dass die Widerrufsrichtlinie eingehalten und die CRL- und OCSP-Infrastruktur regelmäßig getestet wird. CISOs tragen die Verantwortung für die Governance-Entscheidung, dass das Zertifikatslebenszyklusmanagement ein finanziertes, kontinuierliches Programm ist.

Wie hängt die Verwaltung von Zertifikatsablauf und -widerruf mit der Verwaltung des Zertifikatslebenszyklus zusammen?

CLM-Plattformen bilden die operative Ebene, die beide Mechanismen auch bei großem Umfang zuverlässig macht. Eine CLM-Plattform erkennt alle Zertifikate in allen Umgebungen, überwacht deren Ablaufdaten mit automatisierten Erneuerungsbenachrichtigungen und Workflows und ermöglicht die Auslösung von Zertifikatssperrungen bei mehreren Zertifizierungsstellen über eine einzige Schnittstelle. CertSecure Manager verwaltet ein aktuelles Zertifikatsinventar für öffentliche Zertifizierungsstellen, private Zertifizierungsstellenhierarchien, HashiCorp Vault und Microsoft PKI-Umgebungen mit automatisiertem Lebenszyklusmanagement und Echtzeitbenachrichtigungen bei Ablauf- und Sperrereignissen.

Wie sollten Organisationen den Erfolg im Umgang mit Zertifikatsablauf und -widerruf messen?

Wichtige Kennzahlen: Rate ungeplanter Zertifikatsabläufe (Ziel: null pro Quartal, über den gesamten Zertifikatsbestand); Reaktionszeit bei Widerrufen im Falle wichtiger Kompromittierungsereignisse (Ziel: innerhalb von 24 Stunden für öffentlich vertrauenswürdige TLS-Zertifikate gemäß den CA/Browser Forum Baseline Requirements); Erreichbarkeit von CRL und OCSP (Ziel: 100 Prozent der Verteilungspunkte von allen Netzwerksegmenten aus erreichbar, in denen Zertifikate validiert werden, vierteljährlich überprüft); und Vollständigkeit des Zertifikatsinventars (Ziel: alle Zertifikate öffentlicher und privater CA-Quellen sind in der CLM-Plattform vertreten).

Welche Zertifikate sollten regelmäßig auf Ablauf und Widerruf geprüft bzw. überwacht werden?

Kontinuierliche Überwachung: Ablaufdaten von Zertifikaten in allen Umgebungen mit automatisierten Benachrichtigungen zur Verlängerung; Verfügbarkeit von CRL-Verteilungspunkten und OCSP-Respondern für alle aktiven CA-Hierarchien; CA-Ereignisprotokolle für Widerrufsereignisse. Vierteljährliche Prüfung: Test des CRL-Abrufs und der OCSP-Antwort aus repräsentativen Netzwerksegmenten; Überprüfung der Widerrufsrichtlinie anhand der aktuellen Ereignistaxonomie und Bestätigung, dass jedem Ereignistyp ein definierter Verantwortlicher und eine Antwortzeit zugeordnet sind; und Bestätigung, dass certificateHold-Einträge aktiv geprüft und entweder zurückgesetzt oder zu einem endgültigen Widerruf eskaliert werden.

Wie unterscheiden sich Ablauf- und Widerrufsmanagement von Zertifikaten in Cloud-, Hybrid- oder Multi-CA-Umgebungen?

In Cloud- und Hybridumgebungen werden Zertifikate von mehreren Zertifizierungsstellen (CAs) mit separaten CRL-Verteilungspunkten und OCSP-Respondern ausgestellt. Jeder dieser Punkte muss von den Netzwerksegmenten aus erreichbar sein, in denen die ausgestellten Zertifikate validiert werden. Eine CRL, die von lokalen Umgebungen aus zugänglich ist, aber von einer Cloud-Netzwerksicherheitsgruppe blockiert wird, führt zu stillen Widerrufsfehlern in der Cloud-Schicht. CBOM Secure bietet kryptografische Erkennung auf CBOM-Ebene über alle CA-Quellen hinweg und ermöglicht so ein einheitliches Ablauf- und Widerrufsmanagement in Hybridumgebungen.

Welche häufigen Fehler sollten Teams im Zusammenhang mit dem Ablauf und der Widerrufung von Zertifikaten vermeiden?

Die häufigsten Fehler: Verwendung von certificateHold anstelle von permanentem Widerruf bei Schlüsselkompromittierungsereignissen, da ein Widerruf als drastisch empfunden wird (dadurch bleibt ein kompromittiertes Zertifikat in einem wiederherstellbaren Zustand); Bereitstellung von CRL-Verteilungspunkten und OCSP-Respondern ohne Prüfung der Erreichbarkeit aus allen Netzwerksegmenten, in denen Zertifikate validiert werden; Behandlung des Zertifikatsablaufs als einzige Vertrauensgrenze ohne Widerrufsrichtlinie für Ereignisse während des Lebenszyklus; und Annahme, dass die 47-tägige öffentliche TLS-Lebensdauer gemäß CA/Browser Forum SC-081v3 die Notwendigkeit des Widerrufs bei privaten PKI-, Codesignierungs- oder IoT-Gerätezertifikaten, die mehrjährige Gültigkeitszeiträume beibehalten, beseitigt.

Was sollte vierteljährlich im Hinblick auf die Regelungen zum Ablauf und Widerruf von Zertifikaten aktualisiert werden?

Vierteljährlich: CRL-Verteilungspunkt und OCSP-Responder-Erreichbarkeit aus allen Netzwerksegmenten prüfen und Ergebnisse dokumentieren; Zertifikatssperrungen (certificateHold) älter als 30 Tage prüfen und gegebenenfalls zur endgültigen Sperrung eskalieren oder die Gründe formell dokumentieren; Zertifikatsbestand auf Zertifikate prüfen, die außerhalb des verwalteten Lebenszyklus ausgestellt wurden und nicht von der Ablaufüberwachung oder der Sperrrichtlinie abgedeckt sind; und die Taxonomie der Sperrgrundcodes mit den organisatorischen Änderungen des Vorquartals abgleichen. Für die Planung nach der Quantenintegration die Leitlinien zum Algorithmusübergang im PQC Center of Excellence konsultieren.