Bei CRL vs. OCSP geht es darum, wie eine Relying Party erfährt, dass ein Zertifikat vor seinem Ablauf widerrufen wurde. Eine Zertifikatssperrliste (CRL, RFC 5280 §5) ist eine signierte Liste widerrufener Seriennummern, die Clients herunterladen; das Online Certificate Status Protocol (RFC 6960) beantwortet eine Abfrage zu einem einzelnen Zertifikat. Für die öffentliche Web-PKI hat sich die Antwort seit 2024 eindeutig verschoben: CRLs wurden Pflicht, OCSP optional, und die größte CA hat OCSP abgeschaltet.
Auf einen Blick
| CRL | OCSP | |
|---|---|---|
| Spezifikation | RFC 5280 §5 | RFC 6960 (Nonce: RFC 8954) |
| Was der Client erhält | Signierte Liste aller widerrufenen Seriennummern eines Geltungsbereichs | Signierter Status (good, revoked, unknown) für eine Seriennummer |
| Größe (gemessen am 20. Oktober 2026) | CRL-Shard von Let's Encrypt mit 1.591 Einträgen: 62.116 Byte | OCSP-Antwort von DigiCert: 471 Byte |
| Aktualität | thisUpdate bis nextUpdate (dieser Shard: 9 Tage) | Gültigkeit der Antwort (diese Antwort: 7 Tage) |
| Datenschutz | Der Server erfährt nur, dass eine CRL abgerufen wurde | Der Responder erfährt, welche Website der Client besucht |
| Abhängigkeit von der Verfügbarkeit | Lässt sich zwischenspeichern, spiegeln und vorab laden | Live-Abhängigkeit vom Responder, außer bei Stapling |
| Regel der Web-PKI (Baseline Requirements) | Pflicht seit dem 15. März 2024; neue CRL mindestens alle 4 Tage (alle 7, wenn jedes Zertifikat eine OCSP-URL hat) und innerhalb von 24 Stunden nach einem Widerruf | Optional seit dem 15. März 2024 |
| Nutzung im Browser | Aggregiert: Firefox CRLite, Chrome CRLSets | Firefox fragt den Status von DV-Zertifikaten nicht mehr ab (Version 142); Chrome fragt ihn für die meisten Zertifikate nicht ab |
| Auslieferung durch den Server | Nicht zutreffend | OCSP-Stapling (status_request, RFC 6066) |
So funktionieren beide
Eine CRL nennt ihren Aussteller, enthält thisUpdate und nextUpdate, eine monoton steigende CRL-Nummer und einen Eintrag pro widerrufenem Zertifikat (Seriennummer, Widerrufsdatum, optional ein Grund) und ist von der CA signiert. Zertifikate verweisen in der Erweiterung CRL Distribution Points auf ihre CRL; große CAs teilen ihre CRLs in Shards auf, damit jede Datei handhabbar bleibt, und öffentliche CAs legen die vollständige Liste ihrer CRL-URLs in der CCADB offen, damit Aggregatoren jeden Widerruf erfassen können. Clients, die CRLs prüfen, laden sie herunter und speichern sie zwischen; Delta-CRLs (RFC 5280 §5.2.4) können bei großen Listen den Datenverkehr verringern.
Ein OCSP-Client sendet den Hash des Ausstellernamens, den Hash des Ausstellerschlüssels und die Seriennummer an die URL in der Erweiterung Authority Information Access des Zertifikats; der Responder liefert einen signierten Status mit eigenem Gültigkeitszeitraum zurück. Antworten lassen sich bis nextUpdate zwischenspeichern, und Server können eine frische Antwort per Stapling in den TLS-Handshake einbetten, sodass Clients die CA nicht kontaktieren müssen.
Die Messwerte oben wurden live erhoben: Ein im September 2026 ausgestelltes Zertifikat von Let's Encrypt verweist nur auf http://ye2.c.lencr.org/96.crl (keine OCSP-URL), und dieser Shard war 62 KB groß; ein Zertifikat von DigiCert enthält noch http://ocsp.digicert.com, und die Antwort von dort war 471 Byte groß.
Warum OCSP im Web an Bedeutung verlor
Drei Eigenschaften haben Live-OCSP für Browser zu Fall gebracht. Datenschutz: Jede Abfrage verrät der CA, welche Website ein Benutzer von welcher IP-Adresse aus besucht. Verfügbarkeit: Ein langsamer oder unerreichbarer Responder blockiert entweder das Laden von Seiten oder wird stillschweigend ignoriert, weil sich die Browser für Soft-Fail entschieden haben – ein Angreifer, der den Responder blockieren kann, hebelt die Prüfung also aus. Kosten: Responder müssen jeden Seitenaufruf im Internet bewältigen. Stapling löste das Datenschutz- und das Kostenproblem, setzte aber voraus, dass jeder Server seine Antworten zuverlässig aktualisiert, und Must-Staple (RFC 7633), das Stapling durchsetzbar gemacht hätte, wurde nur von Firefox unterstützt.
Das CA/Browser Forum reagierte mit Ballot SC-063 (in Kraft seit dem 15. März 2024): CRLs verpflichtend, OCSP optional. Let's Encrypt entfernte am 7. Mai 2025 die OCSP-URLs aus neuen Zertifikaten und nahm keine Must-Staple-Bestellungen mehr an; am 6. August 2025 schaltete es seine Responder ab. Firefox aktivierte CRLite in Version 137 auf allen Desktop-Installationen: eine kompakte lokale Kodierung jedes Widerrufs unter den in CT-Logs erfassten Zertifikaten, die alle 12 Stunden aktualisiert wird und im Schnitt etwa 300 kB Download pro Tag kostet. Firefox 142 stellte dann die OCSP-Abfragen für domainvalidierte Zertifikate ein. Chrome setzt statt Abfragen pro Website auf CRLSets, eine kuratierte Sammlung, die sich auf Widerrufe mit großer Tragweite konzentriert.
Die dritte Option: kurzlebige Zertifikate
Ein Zertifikat, das nur wenige Tage gültig ist, braucht keine Widerrufsprüfung: Bis sich ein Widerruf verbreitet hätte, ist es bereits abgelaufen. Die Baseline Requirements erlauben CAs, bei kurzlebigen Zertifikaten auf Widerrufsinformationen zu verzichten (höchstens 7 Tage Laufzeit bei Ausstellung ab dem 15. März 2026), und Let's Encrypt bietet seit Januar 2026 über sein ACME-Profil shortlived Zertifikate mit 160 Stunden Laufzeit an. Zusammen mit der allgemeinen Verkürzung der Laufzeit auf 47 Tage bis 2029 (Ballot SC-081v3) wird der Widerruf zur Rückfallebene statt zur primären Schutzmaßnahme. Der Rechner für Zertifikatslaufzeiten zeigt die Grenzen nach Ausstellungsdatum.
Wann welches Verfahren passt
- Öffentliche TLS-Server: Du musst nichts Besonderes tun; stelle sicher, dass deine Zertifikate von einer CA stammen, die CRLs veröffentlicht, und aktiviere Must-Staple nicht. Entferne Stapling-Konfiguration, die scheitert, wenn keine OCSP-URL vorhanden ist.
- Client-Software, die öffentliche Zertifikate prüft: Verwende den Verifizierer der Plattform; er wendet die gebündelten Widerrufsdaten der Browserhersteller an, wo sie verfügbar sind.
- Private PKI mit vielen Clients, teils offline: CRLs mit kurzem
nextUpdate, ausgeliefert über hochverfügbares HTTP. - Private PKI mit besonders schutzbedürftigen Zertifikaten und Online-Clients: OCSP, mit Stapling, wo das Protokoll es unterstützt, und mit Hard-Fail-Richtlinien, wenn du den Responder selbst betreibst.
- Workload- und Dienstidentitäten: kurzlebige Zertifikate (Stunden bis Tage), automatisch ausgestellt, ganz ohne Widerrufsinfrastruktur.
- Codesignatur und Dokumentsignaturen: Bei langlebigen Signaturen zählt der Widerruf weiterhin; kombiniere CRLs oder OCSP mit Zeitstempeln, damit Verifizierer den Status zum Zeitpunkt der Signatur prüfen können.
Hinweise zur Migration
- Erfasse Abhängigkeiten von OCSP: Stapling-Konfiguration auf Servern, Clients, die ohne OCSP mit Hard-Fail abbrechen, Monitoring, das Responder prüft.
- Mach Stapling optional: nginx und Apache dürfen den Start nicht verweigern, wenn ein Zertifikat keine OCSP-URL hat.
- Veröffentliche bei privaten CAs zuerst CRLs: Trage CRL Distribution Points in neue Zertifikate ein, teile große Listen in Shards auf, setze
nextUpdatepassend zu deinem Widerrufs-SLA und liefere die CRLs über HTTP aus (nicht über HTTPS, um zirkuläre Abhängigkeiten zu vermeiden). - Verkürze die Laufzeiten, wo die Automatisierung es erlaubt; jeder Schritt verringert, was der Widerruf leisten muss.
- Teste den Widerruf von Ende zu Ende: Widerrufe ein Testzertifikat und stelle sicher, dass Clients es innerhalb der erwarteten Zeit ablehnen. Der CRL-Decoder und der OCSP-Decoder zeigen, was Clients sehen werden.