CRL – Certificate Revocation List
Abkürzung: CRL
Ein Zertifikat trägt sein Ablaufdatum in sich. Was es nicht in sich trägt, ist die Information, dass es vorzeitig zurückgezogen wurde — etwa weil der private Schlüssel abhanden kam oder der Inhaber die Domain aufgegeben hat. Dafür braucht es eine Auskunft von außen, und die Sperrliste ist die älteste Form davon.
Was in einer Sperrliste steht
Die Liste enthält nicht die Zertifikate selbst, sondern nur deren Seriennummern — jede Zertifizierungsstelle vergibt sie eindeutig. Je Eintrag kommen das Sperrdatum und optional ein Grund dazu, etwa keyCompromise, cessationOfOperation oder superseded.
Dazu zwei Zeitangaben, an denen die Nutzbarkeit hängt: thisUpdate nennt den Ausstellungszeitpunkt, nextUpdate den spätesten Zeitpunkt der nächsten Ausgabe. Das Ganze ist von der ausstellenden Stelle signiert, lässt sich also nicht unterwegs verändern.
Wichtig ist, was nicht darin steht: abgelaufene Zertifikate. Sie fallen nach Ablauf aus der Liste, weil sie ohnehin nicht mehr gelten. Die Liste wächst also nicht unbegrenzt.
Wie der Client sie findet
Im Zertifikat steht die Erweiterung CRL Distribution Points mit einer oder mehreren URLs. Der Client lädt die Liste dort, prüft deren Signatur und sucht die Seriennummer.
Die Abfrage erfolgt bewusst unverschlüsselt über HTTP. Der Grund ist Zirkularität: Eine HTTPS-Verbindung zum Sperrlistenserver bräuchte selbst eine Zertifikatsprüfung, die wiederum eine Sperrliste erfordern würde. Da die Liste signiert ist, schadet der Klartexttransport nicht.
Die beiden Grundprobleme
Größe. Eine Zertifizierungsstelle mit Millionen Zertifikaten erzeugt Listen, die für jeden einzelnen Verbindungsaufbau zu groß sind. Teillisten — Delta-CRLs, die nur die Änderungen seit der letzten Vollausgabe enthalten — mildern das, lösen es aber nicht.
Aktualität. Zwischen thisUpdate und nextUpdate liegen typischerweise Stunden bis Tage. In diesem Fenster gilt ein längst gesperrtes Zertifikat für jeden Client als einwandfrei, der die vorige Liste hat. Genau in diesem Fenster findet ein Missbrauch statt.
Soft-Fail — warum Sperrung selten wirkt
Entscheidend ist aber ein drittes Problem, und es betrifft jedes Sperrverfahren gleichermaßen.
Was soll ein Client tun, wenn die Sperrliste nicht erreichbar ist? Die strenge Antwort wäre, die Verbindung abzulehnen. Praktisch hätte das zur Folge, dass ein Ausfall oder eine Überlastung beim Listenserver alle Verbindungen zu allen Zertifikaten dieser Stelle beendet. Das ist niemandem zumutbar, und so entscheiden Clients im Zweifel für die Verbindung — Soft-Fail.
Daraus folgt die unangenehme Einsicht: Ein Angreifer, der den Abruf der Sperrliste blockieren kann, hebelt die Sperrung aus. Und wer den Netzverkehr so weit beeinflusst, dass er ein gestohlenes Zertifikat einsetzen kann, kann meist auch einen HTTP-Abruf unterdrücken.
Die Sperrprüfung schützt daher vor dem versehentlich weiterverwendeten Zertifikat, nicht vor dem gezielten Angriff. Die eigentliche Gegenmaßnahme ist eine kurze Gültigkeitsdauer: Zertifikate, die nach wenigen Wochen ohnehin ablaufen, brauchen kaum Sperrung.
Die Rückkehr der Sperrlisten
Lange galten Sperrlisten als überholt und OCSP als Nachfolger. Diese Richtung hat sich umgekehrt.
Let's Encrypt hat seine OCSP-Responder am 6. August 2025 abgeschaltet und stellt Sperrinformationen ausschließlich über Sperrlisten bereit. Ausschlaggebend war der Datenschutz: Eine OCSP-Abfrage verrät dem Betreiber des Responders, welche Seite ein Nutzer gerade aufruft — eine Sperrliste nicht, weil sie vollständig geladen wird.
Die Browserhersteller gehen denselben Weg, aber mit eigener Mechanik: Sie sammeln die Sperrlisten zentral ein, pressen sie in kompakte Datenstrukturen und verteilen diese mit ihren eigenen Aktualisierungen an die Installationen. Der Client fragt dann niemanden mehr, sondern schaut lokal nach. Damit entfallen Latenz, Datenschutzproblem und Soft-Fail in einem Schritt.