CRL-Veröffentlichung der Offline Root – der elegante Weg ohne Netzwerk

Kurzfassung vorab: Die Offline Root steht bewusst ohne Netzwerk da — und trotzdem muss ihre Sperrliste (CRL) für die ganze PKI erreichbar sein. Der Trick ist simpel und wird trotzdem ständig falsch gemacht: Die Root signiert eine CRL mit langer Gültigkeit, du transportierst sie einmalig manuell auf einen erreichbaren Webserver, und alle Konsumenten holen sie sich von dort. Die mit Abstand häufigste Katastrophe in diesem Bereich ist die abgelaufene Root-CRL — sie legt von einer Sekunde auf die andere die komplette Vertrauenskette lahm.

Abb. 1: CRL-Veröffentlichung der Offline Root — manueller Transport per Datenträger auf einen erreichbaren CDP/AIA-Webserver, von dem alle Konsumenten die Sperrliste beziehen.

1. Das Grundproblem in einem Absatz

Jedes Zertifikat, das auf die Root zurückführt, verweist in seinen Erweiterungen auf einen CRL-Verteilungspunkt (CDP) — eine URL, unter der die Sperrliste der ausstellenden Instanz abrufbar sein soll. Bei der Issuing CA ist das unkritisch, weil sie online ist. Bei der Offline Root entsteht ein Widerspruch: Ihr CDP-Verweis muss auf eine erreichbare Adresse zeigen, obwohl die Root selbst nie im Netz hängt. Wenn ein Client die Vertrauenskette prüft und die Root-CRL nicht erreicht, gilt die Kette als nicht validierbar — und Anmeldungen, TLS-Verbindungen oder Signaturprüfungen scheitern.

Die Lösung ist konzeptionell einfach: Die Root-CRL wird nicht von der Root ausgeliefert, sondern von einem ganz normalen Webserver, auf den du sie manuell kopierst. Der CDP-Verweis im Root-Zertifikat zeigt von Anfang an auf diese Webserver-URL, nicht auf die Root selbst. Damit ist der Widerspruch aufgelöst — die Root bleibt offline, die CRL ist trotzdem erreichbar.

2. Die lange Gültigkeit — der Kern der Eleganz

Weil der CRL-Transport manuell läuft, willst du ihn so selten wie möglich machen. Genau dafür bekommt die Root-CRL eine bewusst lange Gültigkeit. Während eine Issuing CA ihre CRL typischerweise täglich oder wöchentlich neu schreibt, gibt man der Offline Root gern 26 bis 52 Wochen. Das ist vertretbar, weil sich an der Root-Ebene fast nie etwas ändert: Sie signiert nur eine Handvoll Sub-CA-Zertifikate, und die werden praktisch nie vorzeitig gesperrt.

Den Wert setzt du auf der Offline Root mit certutil. Wichtig ist neben der Gültigkeit (CRLPeriod) auch das Überlappungsfenster (CRLOverlapPeriod), das festlegt, wie lange vor Ablauf eine neue CRL schon als gültig gilt — der Puffer, der dich vor dem Super-GAU bewahrt:

Abb. 2: CRL-Lebenszyklus mit Überlappung — die neue CRL wird zur Halbzeit signiert, sodass bei Verzögerung kein Validierungsausfall entsteht.

Das Überlappungsfenster ist der eigentliche Sicherheitsgurt. Erneuerst du die CRL spätestens zur Halbzeit ihrer Gültigkeit, hast du bei Urlaub, Krankheit oder schlichtem Vergessen noch Wochen Puffer, bevor etwas bricht. Ohne Überlappung läuft die alte CRL exakt in dem Moment ab, in dem du eigentlich die neue einspielen wolltest — und genau an dem Tag ist erfahrungsgemäß der Verantwortliche krank.

3. Der Veröffentlichungsweg Schritt für Schritt

Der eigentliche Ablauf ist Routine, sobald er einmal sauber eingerichtet ist. So sieht der wiederkehrende Vorgang aus, den du ein- bis zweimal im Jahr durchführst:

4. Die typischen Fallen

Drei Fehler sehe ich immer wieder, und alle drei sind mit etwas Vorausschau vermeidbar:

Die mit Abstand teuerste Falle ist die erste. Eine abgelaufene Root-CRL ist kein schleichendes Problem, das sich ankündigt — sie schlägt schlagartig zu, betrifft alle Zertifikate gleichzeitig und führt regelmäßig zu einem unternehmensweiten Ausfall, bei dem niemand sofort versteht, warum plötzlich gar nichts mehr geht. Wer die Überlappung und einen Kalendertermin einrichtet, hat dieses Risiko mit zehn Minuten Aufwand dauerhaft erledigt.

5. Praxis-Beispiel — die Trendforge Digital GmbH

Die Trendforge Digital GmbH, das cloud-affine Scaleup, war nach einem ESC-Redesign frisch auf eine saubere zweistufige Hierarchie umgezogen. Bei der Einrichtung der Offline Root stand die Frage im Raum, wie man die CRL-Veröffentlichung in einer ansonsten weitgehend automatisierten, cloud-lastigen Umgebung handhabt — manuelle Datenträger-Transporte passten schlecht ins Selbstbild des Teams.

Die Lösung war pragmatisch: Wir haben der Root-CRL eine Gültigkeit von 52 Wochen mit 12 Wochen Überlappung gegeben und den CDP-Verweis auf einen ohnehin vorhandenen internen Webserver gelegt, der unter „http://pki.trendforge.local/" erreichbar ist. Der einmalige Transport im Jahr wurde als fester Prozess mit Checkliste und Vier-Augen-Freigabe dokumentiert — passend zur Audit-Erwartung des Investors. Zusätzlich überwacht ihr Monitoring-System das „Next Update" der veröffentlichten CRL und alarmiert, sobald weniger als acht Wochen Restlaufzeit übrig sind.

Das Ergebnis: ein Vorgang, der das Team einmal im Jahr eine halbe Stunde kostet, dafür aber das größte Einzelrisiko der gesamten PKI — den stillen CRL-Ablauf — zuverlässig ausschließt. Genau die Art unspektakulärer Sorgfalt, die im Normalbetrieb niemand bemerkt und deren Fehlen im Ernstfall einen ganzen Arbeitstag kostet.

Verwandte Themen

Pillar-Seite: Active Directory Certificate Services – der komplette Leitfaden

Häufige Fragen (FAQ)

Warum braucht eine Offline Root überhaupt eine CRL?

Weil jedes Zertifikat in der Kette bei der Validierung prüft, ob die ausstellende Instanz das übergeordnete Zertifikat zurückgezogen hat. Auch wenn die Root praktisch nie ein Sub-CA-Zertifikat sperrt, muss ihre Sperrliste erreichbar sein — sonst gilt die Kette als nicht validierbar und Anmeldungen oder TLS-Verbindungen scheitern. Die CRL muss existieren und abrufbar sein, selbst wenn sie leer ist.

Wie lange sollte die Root-CRL gültig sein?

Üblich sind 26 bis 52 Wochen. Die lange Gültigkeit ist vertretbar, weil sich an der Root-Ebene fast nie etwas ändert — sie signiert nur wenige Sub-CA-Zertifikate. Wichtig ist, zusätzlich ein Überlappungsfenster zu setzen, damit die neue CRL schon Wochen vor Ablauf der alten gültig wird und kein Validierungsausfall entsteht.

Was passiert, wenn die Root-CRL abläuft?

Dann bricht die gesamte Vertrauenskette auf einen Schlag zusammen: Alle Zertifikate, die auf die Root zurückführen, gelten als nicht validierbar, Anmeldungen und TLS-Verbindungen scheitern flächendeckend. Das Tückische ist, dass es schlagartig passiert und alle Systeme gleichzeitig betrifft. Genau deshalb sind Überlappungsfenster und ein Kalendertermin zur Halbzeit Pflicht.

Wie kommt die CRL von der offline stehenden Root auf den Webserver?

Manuell per geprüftem Datenträger. Die Root wird kurz hochgefahren, erzeugt mit „certutil -CRL" eine frische Sperrliste, diese wird auf einen USB-Datenträger exportiert, physisch zum CDP/AIA-Webserver getragen und dort ins Veröffentlichungsverzeichnis kopiert. Anschließend prüfst du mit „certutil -URL", dass sie unter der CDP-URL erreichbar ist.

Wohin muss der CDP-Verweis der Root zeigen?

Auf eine erreichbare Webserver-URL, niemals auf die Root selbst — die ist ja offline. Dieser Verweis wird bei der Einrichtung der Root festgelegt und in jedes ausgestellte Sub-CA-Zertifikat eingebrannt. Deshalb muss die Veröffentlichungs-URL feststehen, bevor die Root das erste Mal signiert; eine spätere Änderung erzwingt die Neuausstellung der Sub-CA-Zertifikate.

Brauche ich Delta-CRLs auf der Offline Root?

Nein. Delta-CRLs lohnen sich nur bei häufig wechselnden Sperrlisten, was auf der Root nicht der Fall ist. Auf der Offline Root schaltet man sie ab (CRLDeltaPeriodUnits 0), weil sie nur zusätzlichen Verwaltungsaufwand erzeugen, ohne einen Nutzen zu liefern. Delta-CRLs sind ein Thema der Issuing-Ebene, nicht der Root.

Nächste Schritte mit boddenberg.de

Die CRL-Veröffentlichung der Offline Root ist ein kleiner Baustein mit großer Hebelwirkung — falsch gemacht, legt sie die ganze PKI lahm. Drei Wege, das sauber aufzusetzen:

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund