Zertifikatssperrung einfach erklärt: CRL, OCSP und Stapling

Ein Zertifikat gilt bis zu seinem Ablaufdatum. Was aber, wenn vorher etwas schiefgeht, etwa weil der private Schlüssel gestohlen wurde? Dann muss die Zertifizierungsstelle das Zertifikat sperren (widerrufen, englisch revoke), und Browser müssen davon erfahren. Genau das ist schwieriger, als es klingt. Dieser Artikel erklärt Sperrlisten (CRL), das Online-Protokoll OCSP und OCSP Stapling, warum OCSP gerade abgeschafft wird, wie Browser heute Sperrungen prüfen und warum immer kürzere Laufzeiten das Problem entschärfen.

Warum Zertifikate gesperrt werden

Typische Gründe für eine Sperrung sind:

Schlüssel kompromittiert: Der private Schlüssel wurde gestohlen, versehentlich veröffentlicht oder auf einem gehackten Server gefunden.
Fehler der CA: Das Zertifikat wurde falsch geprüft oder enthält unzulässige Angaben.
Domain abgegeben: Der Inhaber kontrolliert die Domain nicht mehr.
Ersetzt: Das Zertifikat wurde durch ein neues abgelöst und wird nicht mehr gebraucht.

Nach den Regeln des CA/Browser Forums muss eine CA bei einem kompromittierten Schlüssel innerhalb von 24 Stunden sperren, bei den meisten anderen Gründen innerhalb von fünf Tagen. Die Regeln selbst erklärt Zertifizierungsstelle (CA) einfach erklärt.

Sperrlisten (CRL)

Die älteste Methode ist die Certificate Revocation List (CRL): eine von der CA signierte Liste mit den Seriennummern aller gesperrten, noch nicht abgelaufenen Zertifikate, jeweils mit Datum und oft einem Grund. Die Adresse der Liste steht im Zertifikat im Feld CRL Distribution Points; den Aufbau des Zertifikats erklärt X.509-Zertifikat einfach erklärt.

Ein echtes Beispiel: Das Zertifikat von techuni.de verweist auf die Liste ye1.c.lencr.org/27.crl. Am 7. November 2026 war diese Datei 99.705 Byte groß, enthielt 2.317 gesperrte Seriennummern, war um 09:51 UTC erstellt worden und galt bis zum 16. November. Let’s Encrypt verteilt die gesperrten Zertifikate auf viele solche Teillisten, damit keine einzelne Datei zu groß wird. Das ist das alte Problem der CRL: Große CAs hatten früher Listen von vielen Megabyte, die kein Browser bei jedem Seitenaufruf laden kann.

OCSP: einzeln nachfragen

Das Online Certificate Status Protocol (OCSP) sollte das lösen. Statt der ganzen Liste fragt der Browser beim OCSP-Server der CA nach genau einem Zertifikat und erhält eine signierte Antwort: gültig, gesperrt oder unbekannt. Die Antwort ist einige Tage gültig und kann zwischengespeichert werden.

OCSP hat aber drei Schwächen:

Datenschutz: Die CA erfährt bei jeder Anfrage, welche Website Sie gerade besuchen, samt Ihrer IP-Adresse.
Geschwindigkeit: Die zusätzliche Anfrage verzögert den Seitenaufbau.
Zuverlässigkeit: Ist der OCSP-Server nicht erreichbar, müsste der Browser die Seite blockieren. Weil das zu viele Ausfälle verursacht hätte, akzeptieren Browser die Seite in diesem Fall trotzdem (soft fail). Ein Angreifer, der die Verbindung kontrolliert, muss also nur die OCSP-Anfrage blockieren.

Chrome hat deshalb schon 2012 die Online-Abfrage für normale Zertifikate abgeschaltet.

Zwei Spalten: Die Sperrliste wird komplett geladen, im Beispiel 99.705 Byte mit 2.317 Einträgen; OCSP fragt einzeln, verrät der CA die besuchte Website und lässt bei Ausfall die Seite trotzdem laden. — CRL und OCSP (Sperrliste ye1.c.lencr.org/27.crl vom 7.11.2026).

OCSP Stapling: der Server bringt die Antwort mit

Beim OCSP Stapling holt der Webserver selbst regelmäßig die OCSP-Antwort für sein Zertifikat und heftet sie beim TLS-Verbindungsaufbau an (englisch to staple, heften). Der Browser bekommt die signierte Antwort ohne eigene Anfrage, die CA erfährt nichts über die Besucher, und der Seitenaufbau wird nicht langsamer. Wie der Verbindungsaufbau abläuft, steht in wie funktioniert HTTPS.

Mit der Erweiterung Must-Staple konnte ein Zertifikat sogar verlangen, dass der Server immer eine Antwort mitliefert. Durchgesetzt hat sich das nie: Viele Server stapelten unzuverlässig, und nur Firefox wertete Must-Staple aus.

Warum OCSP abgeschafft wird

Seit dem 15. März 2024 erlauben die Regeln des CA/Browser Forums den CAs, auf OCSP zu verzichten; Sperrlisten sind dagegen Pflicht. Let’s Encrypt, die größte CA, hat diesen Weg konsequent beschritten:

5. Dezember 2024: Ankündigung des Ausstiegs, vor allem aus Datenschutzgründen.
30. Januar 2025: Anträge auf Must-Staple-Zertifikate werden abgelehnt.
7. Mai 2025: Neue Zertifikate enthalten keine OCSP-Adresse mehr, nur noch eine CRL-Adresse.
6. August 2025: Die OCSP-Server werden abgeschaltet.

Für die meisten Websites änderte das nichts. Probleme bekamen nur Programme, die OCSP zwingend erwarteten, etwa manche VPN-Gateways oder Mailserver, die nachkonfiguriert werden mussten. Zu VPNs siehe wie funktioniert ein VPN.

Vier Schritte: Ankündigung am 5. Dezember 2024, Ende von Must-Staple am 30. Januar 2025, keine OCSP-Adresse ab 7. Mai 2025, Abschaltung am 6. August 2025. — Zeitplan des OCSP-Ausstiegs von Let’s Encrypt.

Wie Browser heute Sperrungen prüfen

Statt bei jedem Seitenaufruf nachzufragen, bekommen Browser die Sperrinformationen gebündelt über ihre Update-Kanäle:

Chrome nutzt CRLSets, eine vom Hersteller zusammengestellte Auswahl wichtiger Sperrungen, etwa von Zwischenzertifikaten oder nach bekannt gewordenen Vorfällen.
Firefox nutzt CRLite: Mozilla sammelt die Sperrlisten aller CAs und komprimiert sie mit einem Filterverfahren so stark, dass der Status aller öffentlichen Zertifikate in wenigen Megabyte Platz findet.
Apple verteilt ebenfalls eigene Sperrdaten an seine Geräte.

So bleibt die Prüfung privat und schnell, weil sie lokal im Browser stattfindet.

Kurzlebige Zertifikate statt Sperrung

Die eleganteste Lösung ist, Sperrungen überflüssig zu machen: Ein Zertifikat, das nach wenigen Tagen abläuft, muss man kaum sperren. Seit 2024 erlauben die Regeln, dass sehr kurzlebige Zertifikate ohne Sperrinformationen auskommen; seit März 2026 gilt dafür eine Höchstlaufzeit von 7 Tagen. Let’s Encrypt bietet bereits Zertifikate mit 160 Stunden (rund 6,7 Tagen) Laufzeit an. Rechenbeispiel: Wird ein Schlüssel gestohlen und das Zertifikat nicht gesperrt, ist ein Angreifer bei 90 Tagen Laufzeit im schlimmsten Fall 90 Tage im Vorteil, bei 160 Stunden höchstens knapp 7 Tage. Mit der allgemeinen Verkürzung auf 47 Tage bis 2029 schrumpft dieses Zeitfenster auch für normale Zertifikate.

Balkendiagramm der Laufzeiten: 398, 200, 90, 47 Tage und 160 Stunden; so lange könnte ein gestohlener Schlüssel ohne wirksame Sperrung höchstens genutzt werden. — Kurze Laufzeiten begrenzen den Schaden ohne Sperrung.

Häufige Fragen

Merke ich als Nutzer, wenn ein Zertifikat gesperrt ist? Ja, wenn der Browser die Sperrung kennt, zeigt er eine Warnseite, in Chrome etwa mit dem Code NET::ERR_CERT_REVOKED.

Kann ich prüfen, ob ein Zertifikat gesperrt ist? Ja. Die Sperrliste steht im Zertifikat und lässt sich herunterladen; openssl crl -in liste.crl -inform DER -noout -text zeigt die Seriennummern.

Was soll ich tun, wenn mein Schlüssel gestohlen wurde? Sofort das Zertifikat bei der CA sperren lassen, einen neuen Schlüssel erzeugen und ein neues Zertifikat beantragen. Bei Let’s Encrypt erledigt das certbot revoke.

Funktioniert OCSP noch irgendwo? Einige CAs betreiben OCSP weiter, vor allem für Firmen- und Behördenanwendungen. Für Websites spielt es kaum noch eine Rolle.

Fazit

Gesperrte Zertifikate zuverlässig zu erkennen war lange ein ungelöstes Problem: Sperrlisten waren zu groß, OCSP verriet das Surfverhalten und versagte still. Heute verteilen Browser Sperrdaten gebündelt, Let’s Encrypt hat OCSP abgeschaltet, und immer kürzere Laufzeiten machen Sperrungen zunehmend überflüssig. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.