Was am 6. August 2025 endgültig zu Ende ging
Das Online Certificate Status Protocol ist in RFC 6960 spezifiziert (IETF, RFC 6960). Die Idee war elegant: Statt eine komplette Sperrliste herunterzuladen, fragt der Client für genau ein Zertifikat nach — „ist diese Seriennummer gesperrt?" — und erhält eine signierte Antwort der Zertifizierungsstelle. In der Praxis hat dieses Modell drei Schwächen, die es über zwei Jahrzehnte kaum losgeworden ist: Es kostet eine zusätzliche Netzwerkrunde beim Verbindungsaufbau, es fällt bei Nichterreichbarkeit typischerweise auf „soft-fail" zurück — der Client verbindet also trotzdem — und es verrät der CA, welche Seite ein Nutzer gerade aufruft.
Let's Encrypt hat den Ausstieg am 5. Dezember 2024 angekündigt und in drei Schritten vollzogen (Let's Encrypt, „Ending OCSP Support in 2025): Ab dem 30. Januar 2025 schlugen Anfragen mit der OCSP-Must-Staple-Erweiterung für Accounts fehl, die zuvor kein solches Zertifikat bezogen hatten. Am 7. Mai 2025 verschwanden die OCSP-URLs aus neu ausgestellten Zertifikaten. Am 6. August 2025 gingen die Responder aus. Der Dienst lief rund zehn Jahre; zuletzt trug ein CDN 140.000 Anfragen pro Sekunde, während 15.000 Anfragen pro Sekunde am Origin ankamen (Let's Encrypt, „OCSP Service Has Reached End of Life).
Wer eine Seite über HTTPS aufruft und dabei eine OCSP-Abfrage auslöst, teilt der Zertifizierungsstelle mit, welche Website von welcher IP-Adresse gerade besucht wird. Let's Encrypt nennt genau das als Hauptgrund für die Abschaltung: Selbst wenn eine CA diese Daten bewusst nicht speichert, könnte sie rechtlich zur Erhebung verpflichtet werden (Let's Encrypt, „Ending OCSP Support in 2025). Für Betreiber in der EU ist das mehr als eine Fußnote — es ist ein Datenfluss an einen Dritten, der bei jedem Verbindungsaufbau entstehen kann.
Let's Encrypt veröffentlicht Sperrinformationen seit September 2022 zusätzlich als CRL und seit dem 6. August 2025 ausschließlich auf diesem Weg (Let's Encrypt, „OCSP Service Has Reached End of Life). Der wichtigste Punkt dabei: Die Sperrinformation ist nicht verschwunden. Sie hat den Kanal gewechselt. Wer SSL-Monitoring als laufende Aufgabe betreibt, muss deshalb neu bewerten, welche Prüfungen überhaupt noch aussagekräftig sind.
CRLs: der verpflichtende Publikationsweg der CAs
Die Weichen dafür wurden lange vor der Abschaltung gestellt. Mit Ballot SC-063 hat das CA/Browser Forum im Juli 2023 beschlossen, OCSP optional zu machen und CRLs verpflichtend vorzuschreiben. Die Abstimmung ging bei den Zertifikatsausstellern mit 28 Ja- zu 1 Nein-Stimme aus, bei den Browser-Herstellern einstimmig mit 3 zu 0 (CA/Browser Forum, Ballot SC-063). Wirksam wurden die Anforderungen am 15. März 2024 (CA/Browser Forum, Ballot SC-063). Seitdem gilt: Eine CA darf OCSP anbieten — führen muss sie CRLs.
- Neue CRL nach höchstens 24 Stunden: Nach dem Vermerk einer Sperrung muss die CA innerhalb von 24 Stunden eine aktualisierte CRL veröffentlichen (CA/Browser Forum, Ballot SC-063).
- Regelmäßige Aktualisierung: Mindestens alle sieben Tage, wenn die Zertifikate eine AIA-Erweiterung mit OCSP-Verweis enthalten — sonst mindestens alle vier Tage (CA/Browser Forum, Ballot SC-063).
- Definiertes Profil: Die CRL muss dem vorgeschriebenen Profil entsprechen, das auf dem CRL-Profil aus RFC 5280 aufsetzt (IETF, RFC 5280).
- Vollständigkeit: Die veröffentlichten Listen müssen den gesamten Bestand abdecken — entweder als eine Liste oder als partitionierte Listen, die zusammen den vollständigen Bestand ergeben (CA/Browser Forum, Ballot SC-063).
- OCSP bleibt erlaubt: Wer OCSP weiterhin betreibt, unterliegt unverändert den bisherigen Anforderungen (CA/Browser Forum, Ballot SC-063).
Damit ist eine Seite der Gleichung sauber gelöst: Die Sperrinformation wird zuverlässig und in definierten Fristen publiziert. Mozilla zählt im eigenen Root-Programm rund 3.000 aktive CRLs, die von Zertifizierungsstellen offengelegt werden (Mozilla Security Blog, CRLite). Wer wissen will, welche Zertifikate für seine Domains überhaupt existieren, kombiniert das sinnvollerweise mit Certificate-Transparency-Monitoring — CT zeigt die Ausstellung, die CRL den Widerruf.
Die CRL-Pflicht regelt, was die Zertifizierungsstelle tun muss. Sie regelt nicht, was der Browser damit macht. Genau an dieser Stelle brechen die meisten Annahmen: Eine korrekt und fristgerecht veröffentlichte Sperrung ist kein Beleg dafür, dass ein Besucher Ihre gesperrte Seite nicht mehr erreicht.
Was der Browser wirklich prüft: CRLSets und CRLite
Kein verbreiteter Browser lädt bei jedem Verbindungsaufbau eine rund 300 MB große Sammlung von Sperrlisten herunter — in dieser Größenordnung liegt die Gesamtmenge aller CRLs im Mozilla-Root-Programm (Mozilla Security Blog, CRLite). Stattdessen aggregieren die Hersteller. Chrome nutzt CRLSets: von Google zusammengestellte Listen, die mit dem Browser verteilt werden. Online-Abfragen per OCSP oder CRL finden standardmäßig nicht statt (Chromium Project, Chrome Root Store FAQ).
„Zeitüberschreitungen … Angreifer im lokalen Netz können ‚Online'-Abfragen blockieren … OCSP gibt den Browserverlauf an Dritte preis … CRLs können ziemlich groß sein."
— Chromium Project, Chrome Root Store FAQ — zu den systematischen Schwächen von Sperrabfragen (Übersetzung)
Der entscheidende Punkt ist der Umfang. Ein aktuelles CRLSet ist rund 600 kB groß und deckt etwa 1 Prozent aller Sperrungen ab — rund 35.000 von insgesamt vier Millionen (Mozilla Security Blog, CRLite). Firefox geht seit Version 137 einen anderen Weg: CRLite verteilt den vollständigen Sperrbestand der Web-PKI komprimiert an die Clients, die dann lokal und ohne Netzwerkabfrage prüfen (Mozilla Security Blog, CRLite).
| Client | Verfahren | Abdeckung | Was das für Ihre Sperrung bedeutet |
|---|---|---|---|
| Chrome / Chromium | CRLSet, mit dem Browser verteilt | rund 1 % der Sperrungen (Mozilla Security Blog, CRLite) | Greift vor allem bei Sperrgrund keyCompromise oder privilegeWithdrawn (Chromium Project, Chrome Root Store FAQ) |
| Firefox ab Version 137 | CRLite, vollständiger Bestand lokal | Web-PKI weitgehend vollständig (Mozilla Security Blog, CRLite) | Sperrung wird in der Regel zeitnah wirksam, ohne Abfrage an die CA |
| Ältere Firefox-Versionen | OCSP-Live-Abfrage | abhängig vom Responder | Ohne erreichbaren Responder bleibt typischerweise nur Soft-Fail |
| Clients außerhalb des Browsers | je nach Bibliothek OCSP oder CRL | sehr unterschiedlich | Hier wirkt die OCSP-Abschaltung am stärksten (Let's Encrypt, „Ending OCSP Support in 2025) |
Die Zahlen dahinter sind der eigentliche Grund für den Umstieg: CRLite-Nutzer laden im Schnitt 300 kB Sperrdaten pro Tag — ein 4-MB-Snapshot alle 45 Tage plus Delta-Updates dazwischen — und sind damit rund tausendmal bandbreiteneffizienter als der tägliche Download aller CRLs (Mozilla Security Blog, CRLite). Der Nebeneffekt ist messbar: OCSP-Abfragen blockierten den TLS-Handshake im Median um 100 Millisekunden; als der CRLite-Anteil 80 Prozent erreichte, sank die mediane Handshake-Zeit von 56,4 auf 39,9 Millisekunden (Mozilla Security Blog, CRLite). Ab Firefox 142 wird OCSP für domainvalidierte Zertifikate ganz abgeschaltet (Mozilla Security Blog, CRLite). Wer seine TLS-Cipher-Suites härtet und überwacht, gewinnt an dieser Stelle also gleich doppelt.
Zwischen „Ich habe das Zertifikat gesperrt" und „Der Browser lehnt es ab" liegt 2026 kein Automatismus. Bei Firefox ab Version 137 ist die Lücke klein, weil CRLite den vollständigen Bestand verteilt (Mozilla Security Blog, CRLite). Bei Chrome hängt es davon ab, ob Ihre Sperrung überhaupt in einem CRLSet landet — was für rund ein Prozent aller Sperrungen zutrifft (Mozilla Security Blog, CRLite). Planen Sie deshalb so, als würde die Sperrung allein Sie nicht retten.
Der Sperrgrund entscheidet: keyCompromise ist kein Detail
Hier steckt der praktisch wichtigste Hebel des ganzen Themas — und er wird regelmäßig übersehen. Chromes Standardverhalten blockt per CRLSet gesperrte CA-Zertifikate sowie Server-Zertifikate, deren Sperrgrund keyCompromise oder privilegeWithdrawn lautet (Chromium Project, Chrome Root Store FAQ). Anders gesagt: Der Sperrgrund entscheidet mit darüber, ob eine Sperrung im meistgenutzten Browser überhaupt eine Chance hat, wirksam zu werden.
Das Problem dabei: Sperrgründe sind optional, und sie werden häufig weggelassen. Nach Mozillas Auswertung fehlt bei etwa der Hälfte aller Sperrungen die Angabe eines Sperrgrunds (Mozilla Security Blog, CRLite). Wer bei einer Kompromittierung schnell handelt und den Sperrgrund auf dem Standardwert belässt, verschenkt genau die Eigenschaft, die den Unterschied macht.
keyCompromise(Code 1) setzen, wenn der private Schlüssel abgeflossen sein könnte — etwa nach einem Server-Einbruch, einem versehentlich veröffentlichten Key oder einem kompromittierten Backup. Dieser Grund undprivilegeWithdrawnsind die für Chromes CRLSet relevanten Werte (Chromium Project, Chrome Root Store FAQ).superseded(Code 4) ist der passende Wert für harmlose Fälle: Zertifikat wurde neu ausgestellt, das alte wird aufgeräumt. Es signalisiert korrekt, dass kein Sicherheitsvorfall vorliegt.- Kein Grund angegeben ist der Standard vieler Werkzeuge — und die schwächste Wahl bei einem echten Vorfall, weil die Sperrung damit für die browserseitige Aggregation kaum verwertbar wird (Chromium Project, Chrome Root Store FAQ).
- Vor dem Ernstfall klären: Der ACME-Standard sieht die Angabe eines Sperrgrunds beim Widerruf vor. Ob Ihr Client das anbietet und wie der Parameter heißt, gehört ins Runbook — und sollte nicht erst nachts um drei recherchiert werden (Projekterfahrung).
Ein kompromittierter Schlüssel wird gesperrt — ohne Sperrgrund, weil das Kommando so am kürzesten war. Die CA publiziert die Sperrung fristgerecht in ihrer CRL (CA/Browser Forum, Ballot SC-063), Firefox setzt sie über CRLite um (Mozilla Security Blog, CRLite), und Chrome lässt sie unberücksichtigt, weil ohne keyCompromise in der Regel kein CRLSet-Eintrag entsteht (Chromium Project, Chrome Root Store FAQ). Das Zertifikat gilt formal als gesperrt und wird in einem großen Teil des Marktes trotzdem weiter akzeptiert. Wer Zertifikate über ACME automatisiert, sollte den Sperrgrund deshalb fest im Ablauf hinterlegen.
Kurzlebigkeit als eigentliche Lösung: 200, 100, 47 und 7 Tage
Das CA/Browser Forum hat aus der Schwäche der Sperrmechanismen eine strategische Konsequenz gezogen: Wenn Sperrung im Web-Maßstab schlecht funktioniert, verkürzt man die Zeit, in der ein Zertifikat überhaupt Schaden anrichten kann. Ballot SC-081v3 wurde im April 2025 angenommen und legt dafür einen Stufenplan fest, der die Maximallaufzeit von 398 Tagen schrittweise auf 47 Tage senkt (CA/Browser Forum, Ballot SC-081v3).
| Ab | Maximale Laufzeit | Praktische Folge |
|---|---|---|
| bis 14.03.2026 | 398 Tage | Manuelle Erneuerung war noch zu stemmen |
| 15.03.2026 | 200 Tage | Bereits in Kraft — rund zwei Erneuerungen pro Jahr |
| 15.03.2027 | 100 Tage | Automatisierung praktisch ohne Alternative |
| 15.03.2029 | 47 Tage | Vollautomatischer Betrieb als Normalfall |
Der Stufenplan stammt aus CA/Browser Forum, Ballot SC-081v3. Parallel dazu sinkt die Wiederverwendbarkeit der Domain-Validierung von 398 Tagen bis 2029 auf 10 Tage (CA/Browser Forum, Ballot SC-081v3) — die Prüfung der Domain-Kontrolle wird damit ebenfalls zum Dauerbetrieb. Die 47 Tage sind übrigens kein Zufallswert: Sie setzen sich aus einem maximal langen Monat (31 Tage), einem halben 30-Tage-Monat (15 Tage) und einem Tag Puffer zusammen (CA/Browser Forum, Ballot SC-081v3). Seit dem 15. März 2026 gilt bereits die 200-Tage-Grenze — was das im Alltag bedeutet, steht im Detail im Beitrag zum 200-Tage-Limit und dem Weg zu 47 Tagen.
Daneben existiert eine zweite Kategorie, die das Sperrproblem elegant umgeht: kurzlebige Zertifikate. Für Zertifikate, die ab dem 15. März 2026 ausgestellt werden, gilt ein Kurzläufer als Zertifikat mit einer Gültigkeit von höchstens sieben Tagen (604.800 Sekunden); zuvor lag die Grenze bei zehn Tagen (CA/Browser Forum, Ballot SC-063). Der Clou: Solche Zertifikate müssen weder CRL-Verteilungspunkte noch OCSP-Verweise enthalten und unterliegen keiner Sperrpflicht (CA/Browser Forum, Ballot SC-063). Die Begründung ist schlicht — ein Zertifikat, das ohnehin in sieben Tagen abläuft, braucht keinen Widerruf, der im Browser kaum ankommt.
Kurzlebige Zertifikate sind seit dem 15. Januar 2026 allgemein verfügbar und gelten 160 Stunden, also gut sechs Tage (Let's Encrypt, 6-Tage- und IP-Zertifikate).
Der Bezug läuft über die Auswahl des Zertifikatsprofils shortlived im ACME-Client. Ein Standard ist es ausdrücklich nicht, und das soll vorerst so bleiben (Let's Encrypt, 6-Tage- und IP-Zertifikate).
Zertifikate auf IP-Adressen — IPv4 wie IPv6 — sind ebenfalls verfügbar und müssen kurzlebig sein (Let's Encrypt, 6-Tage- und IP-Zertifikate).
Wer die Erneuerung vollständig automatisiert hat, kann in der Regel ohne großen Aufwand umstellen; ohne belastbare ACME-Automatisierung ist der Schritt riskant (Let's Encrypt, 6-Tage- und IP-Zertifikate).
Man kann diesen Weg als „Revocation durch Ablauf" bezeichnen: Statt darauf zu hoffen, dass ein Widerruf im Browser ankommt, sorgt man dafür, dass das Zeitfenster von vornherein klein bleibt. Der Preis dafür ist eine Erneuerungskette, die verlässlich laufen muss — deren Ausfall dann allerdings ein Betriebsproblem ist und kein Sicherheitsproblem.
OCSP-Stapling: Konfigurationen, die ins Leere zeigen
OCSP-Stapling dreht das Datenschutzproblem um: Nicht der Browser fragt die CA, sondern der Server holt die signierte Statusantwort selbst ab und liefert sie im TLS-Handshake gleich mit. Das war jahrelang die empfohlene Konfiguration — und genau deshalb steht in vielen Server-Konfigurationen bis heute eine Stapling-Zeile, die auf einen Responder zeigt, den es nicht mehr gibt.
Bei Zertifikaten, die nach dem 7. Mai 2025 von Let's Encrypt ausgestellt wurden, fehlt die OCSP-URL im Zertifikat vollständig (Let's Encrypt, „Ending OCSP Support in 2025). Ein Server mit aktiviertem Stapling findet dann keinen Responder mehr, den er fragen könnte. In der Regel ist das folgenlos, weil die Konfiguration auf einen fehlenden Status tolerant reagiert. Es ist aber unnötiger Ballast, der beim Neustart Fehlermeldungen produziert und im Betrieb Rauschen erzeugt — und Rauschen ist der Grund, warum echte Warnungen übersehen werden (Projekterfahrung).
- Stapling-Direktiven prüfen und abbauen: Enthält das Zertifikat keine OCSP-URL mehr, hat Stapling nichts mehr auszuliefern. Die Direktive kann weg.
- Verweise auf Responder-Dateien entfernen: Vorab geladene Antwortdateien und lokale Caches, die auf einen abgeschalteten Responder zeigen, sind veraltet und gehören aufgeräumt.
- OCSP Must-Staple aus dem Bestand nehmen: Ein Zertifikat mit Must-Staple-Erweiterung, für das keine Antwort mehr existiert, kann Verbindungen aktiv brechen. Let's Encrypt hat entsprechende Anfragen ab dem 30. Januar 2025 schrittweise abgelehnt (Let's Encrypt, „Ending OCSP Support in 2025).
- Clients außerhalb des Browsers inventarisieren: Bibliotheken, Load-Balancer, Mail-Server, mobile Apps und Zahlungs-Integrationen prüfen teils weiterhin per OCSP. Let's Encrypt weist ausdrücklich darauf hin, dass Websites und ihre Besucher von der Umstellung typischerweise nicht betroffen sind, manche Nicht-Browser-Software dagegen schon (Let's Encrypt, „Ending OCSP Support in 2025).
- Ergebnis dokumentieren: Nach dem Umbau festhalten, welcher Sperrweg für welchen Dienst überhaupt noch relevant ist — sonst wandert die tote Konfiguration beim nächsten Server-Umzug einfach mit (Projekterfahrung).
Prüfen Sie, ob Ihre ausgelieferten Zertifikate überhaupt noch eine OCSP-URL in der AIA-Erweiterung tragen. Fehlt sie, ist jede Stapling-Konfiguration auf diesem Host gegenstandslos. Sinnvollerweise prüfen Sie im selben Durchgang die Kette, die Restlaufzeit und die ausgelieferten HTTP-Security-Header — all das hängt an derselben Verbindung und lässt sich gemeinsam bewerten.
Schlüsselkompromittierung 2026: Neuausstellung schlägt Sperrung
Wenn der private Schlüssel kompromittiert ist, lautete die klassische Antwort: sperren. 2026 ist das nur noch der zweite Schritt — und nicht der wirksamste. Die Sperrung bleibt richtig und notwendig, sie ist gegenüber der CA verpflichtend und erzeugt den Eintrag in der CRL (CA/Browser Forum, Ballot SC-063). Aber sie erreicht den Browser nur über die oben beschriebenen Aggregate, bei Chrome zudem nur mit passendem Sperrgrund (Chromium Project, Chrome Root Store FAQ). Der eigentliche Schutz entsteht dadurch, dass das kompromittierte Schlüsselmaterial auf Ihren Systemen nicht mehr existiert.
- Neues Schlüsselpaar erzeugen — nicht das alte wiederverwenden. Ein Zertifikat neu auszustellen, ohne den Schlüssel zu wechseln, löst das Problem nicht.
- Neues Zertifikat ausstellen und ausrollen, bevor gesperrt wird. Wer zuerst sperrt und dann ausrollt, riskiert ein Fenster, in dem gar nichts Gültiges ausgeliefert wird.
- Sperrung mit Sperrgrund
keyCompromisebeantragen — das ist der Grund, der Chromes CRLSet überhaupt erreichen kann (Chromium Project, Chrome Root Store FAQ). - Alten Schlüssel überall entfernen: Load-Balancer, Backup-Hosts, Container-Images, CI-Secrets, Terminierungspunkte im CDN. Ein Schlüssel, der noch irgendwo liegt, ist ein Schlüssel, der noch irgendwo ausgeliefert wird.
- Ausrollen überwachen: Erst wenn jeder Endpunkt das neue Zertifikat ausliefert, ist der Vorfall geschlossen. Bei mehreren Standorten und Load-Balancern ist das ohne Messung von außen schwer zu belegen (Projekterfahrung).
- Meldepflichten prüfen: Je nach Rolle und Betroffenheit kann ein Vorfall dokumentations- oder meldepflichtig sein; in Dienstleisterketten gilt das besonders — siehe NIS2 in der Lieferkette.
„Sperren und hoffen" war schon vor 2025 eine schwache Strategie — mit abgeschalteten Respondern (Let's Encrypt, „OCSP Service Has Reached End of Life) und CRLSets, die rund ein Prozent der Sperrungen abdecken (Mozilla Security Blog, CRLite), ist sie es umso mehr. „Neu ausstellen, schnell ausrollen, sauber sperren" verlagert den Schutz dorthin, wo Sie ihn tatsächlich kontrollieren: auf Ihre eigenen Systeme. Die Sperrung bleibt Pflicht — aber sie ist die Absicherung, nicht der Plan.
Was Monitoring jetzt prüfen muss
Wenn der Sperrmechanismus im Browser faktisch kaum greift, verschiebt sich die Beweislast: Sie müssen selbst wissen, was Ihre Server ausliefern. Das sind vier Prüfungen, die zusammengehören — und die man sinnvollerweise in einem Durchgang erhebt statt in vier getrennten Werkzeugen.
Wird die vollständige Kette ausgeliefert, passt sie zum Hostnamen, und stammt sie von der CA, die Sie erwarten? Eine unvollständige Kette fällt in Browsern oft nicht auf, in anderen Clients dagegen sofort.
Bei 200 Tagen Maximallaufzeit seit dem 15. März 2026 und 100 Tagen ab 2027 (CA/Browser Forum, Ballot SC-081v3) lautet die Frage nicht mehr „läuft es ab", sondern „hat die Automatisierung gegriffen".
Liefert der Server eine Statusantwort mit — und wenn ja, eine gültige? Eine Stapling-Konfiguration, die auf einen abgeschalteten Responder zeigt, gehört erkannt und abgebaut (Let's Encrypt, „OCSP Service Has Reached End of Life).
Protokollversionen, Cipher-Suites und die ausgelieferten Security-Header hängen an derselben Verbindung und lassen sich gemeinsam bewerten.
Das ist genau die Verschiebung, die dieser Artikel beschreibt: weg von der Frage „ist die Sperrung publiziert" — die beantwortet die CA verlässlich und fristgebunden (CA/Browser Forum, Ballot SC-063) — hin zu „was liefert mein Server tatsächlich aus". Der XICTRAQ Security-Scan prüft die TLS-Konfiguration einschließlich Kette, Restlaufzeit, Stapling-Status und Header, statt sich auf einen Mechanismus zu verlassen, der im Browser kaum noch trägt. Auffälligkeiten laufen über die Alarmierung und Benachrichtigungen, die reine Erreichbarkeit der Endpunkte deckt das Uptime-Monitoring ab.
- Von außen messen, nicht von innen: Ein lokaler Aufruf auf dem Host sagt wenig darüber, was ein Load-Balancer oder ein CDN-Knoten in einer anderen Region tatsächlich ausliefert (Projekterfahrung).
- Alle Endpunkte, nicht nur die Startseite: API-Hosts, Mail-Endpunkte, Redirect-Domains und Status-Seiten haben eigene Zertifikate und eigene Erneuerungsketten.
- Ausstellung und Widerruf zusammen denken: CT-Logs zeigen, was ausgestellt wurde, CRLs zeigen, was widerrufen wurde. Beides gehört in dieselbe Übersicht.
- Schwachstellen im Umfeld nicht vergessen: Der TLS-Stack ist Software wie jede andere; welche Lücken für Ihre Komponenten gemeldet sind, gehört in denselben Prozess — siehe EUVD und CVE-Feeds 2026.
Zertifikatssperrung im Griff behalten, ohne sich auf sie zu verlassen
Die Lage 2026 lässt sich in drei Sätzen zusammenfassen. Erstens: Die Sperrinformation wird zuverlässiger publiziert als zuvor — CRLs sind Pflicht, mit klaren Fristen von 24 Stunden nach der Sperrung und vier bis sieben Tagen für die turnusmäßige Aktualisierung (CA/Browser Forum, Ballot SC-063). Zweitens: Der Weg vom Widerruf bis in den Browser ist deutlich indirekter geworden — Chrome deckt über CRLSets rund ein Prozent der Sperrungen ab, Firefox seit Version 137 über CRLite den vollständigen Bestand (Mozilla Security Blog, CRLite). Drittens: Die Antwort der Branche ist nicht ein besserer Sperrmechanismus, sondern kürzere Laufzeiten — 200 Tage seit März 2026 und 47 Tage ab 2029 (CA/Browser Forum, Ballot SC-081v3), dazu sieben Tage für Kurzläufer ganz ohne Sperrpflicht (CA/Browser Forum, Ballot SC-063).
Für den Betrieb heißt das vier Dinge: tote OCSP-Stapling-Konfigurationen abräumen, den Sperrgrund im Notfall-Runbook hinterlegen, die Erneuerung auf eine Automatisierung bringen, der Sie auch bei 100 Tagen Laufzeit vertrauen, und von außen messen, was Ihre Endpunkte ausliefern. Wer das Thema weiterdenken möchte: Der nächste große Umbau der TLS-Schicht läuft bereits — Post-Quantum-TLS mit ML-KEM verändert den Handshake ein weiteres Mal. Und wer Aufwand gegen Nutzen abwägen will, findet die Leistungsumfänge in der Preisübersicht.
Dieser Artikel stützt sich auf: Let's Encrypt — „Ending OCSP Support in 2025" (05.12.2024; Ankündigung und Zeitplan der Abschaltung, Datenschutzbegründung, Hinweise zu Nicht-Browser-Software); Let's Encrypt — „OCSP Service Has Reached End of Life" (06.08.2025; Abschaltung, Abfragevolumen, Umstieg auf CRLs); Let's Encrypt — 6-Tage- und IP-Zertifikate (allgemeine Verfügbarkeit kurzlebiger Zertifikate ab 15.01.2026, Profil shortlived, 160 Stunden Gültigkeit); CA/Browser Forum — Baseline Requirements, Ballot SC-063 („Make OCSP Optional, Require CRLs, and Incentivize Automation"; Abstimmung Juli 2023, wirksam 15.03.2024, CRL-Fristen, Definition kurzlebiger Zertifikate); CA/Browser Forum — Ballot SC-081v3 („Introduce Schedule of Reducing Validity and Data Reuse Periods"; Stufenplan 200/100/47 Tage, DCV-Wiederverwendung); Mozilla Security Blog — CRLite (Rollout in Firefox 137, Abdeckungs-, Größen- und Handshake-Kennzahlen, CRLSet-Vergleich); Chromium Project — Chrome Root Store FAQ (CRLSets, Verzicht auf Live-Abfragen, relevante Sperrgründe, Enterprise-Richtlinien); IETF — RFC 6960 (OCSP) und IETF — RFC 5280 (CRL-Profil). Ergänzt um Erfahrungswerte aus dem laufenden Betrieb (Projekterfahrung).
Häufige Fragen zur Zertifikatssperrung 2026
Merkt der Browser überhaupt, wenn ich ein Zertifikat sperre?
keyCompromise oder privilegeWithdrawn (Chromium Project, Chrome Root Store FAQ). Erfahrungsgemäß sollten Sie sich deshalb nicht allein auf die Sperrung verlassen, sondern zusätzlich ein neues Zertifikat ausstellen und ausrollen.