ADCS OCSP CRL Hochverfuegbarkeit
PKI-Sperrprüfung ohne Single Point of Failure – OCSP und CRL redundant ausgelegtOCSP-Responder und CRL-Hochverfügbarkeit in der Praxis
Eine PKI ist nur so gut wie ihre Sperrprüfung – und die ist genau dann gefragt, wenn es brennt. Wenn deine CRL nicht erreichbar ist oder der OCSP-Responder steht, dann scheitern im schlimmsten Fall TLS-Handshakes, VPN-Verbindungen und Smartcard-Logins reihenweise, und zwar für alle gleichzeitig. Meine klare Haltung: Sperrinformationen gehören hinter einen Load Balancer, Punkt. OCSP ist der schnelle primäre Pfad für die TLS-Welt, die CRL der robuste Fallback – und beide brauchst du redundant. Wer hier spart, baut sich einen Single Point of Failure, der die gesamte PKI mitreißt, obwohl die CA selbst tadellos läuft.
Abb. 1: OCSP und CRL doppelt ausgelegt – fällt ein Knoten aus, validiert die PKI weiter.
1. CRL und OCSP – zwei Verfahren, ein Ziel
Beide beantworten dieselbe Frage: Ist dieses Zertifikat noch gültig oder wurde es gesperrt? Sie tun es nur unterschiedlich. Die CRL (Certificate Revocation List) ist eine signierte Liste aller gesperrten Zertifikate, die der Client herunterlädt und lokal prüft. OCSP (Online Certificate Status Protocol) dreht das um: Der Client fragt für ein einzelnes Zertifikat gezielt nach und bekommt eine signierte Einzelantwort.
|
Kriterium |
CRL |
OCSP |
|---|---|---|
|
Prinzip |
komplette Sperrliste |
Einzelabfrage |
|
Aktualität |
Publishing-Intervall |
nahezu in Echtzeit |
|
Datenvolumen |
wächst mit Sperrungen |
klein, pro Abfrage |
|
Offline nutzbar |
ja, zwischengespeichert |
nein |
|
Rolle |
robuster Fallback |
primärer TLS-Pfad |
In der Praxis brauchst du beides. Moderne Browser und TLS-Stacks bevorzugen OCSP, oft sogar OCSP-Stapling, bei dem der Server die OCSP-Antwort gleich mitliefert. Viele ältere Clients, Maschinen und Spezialanwendungen verlassen sich dagegen weiter auf die CRL. Fällt OCSP aus, ist die CRL der Rettungsanker – und umgekehrt.
Abb. 2: CRL als Fallback, OCSP als primärer Pfad – wann welches Verfahren greift.
2. CDP und AIA über HTTP-Alias veröffentlichen
Damit Clients die Sperrinformationen überhaupt finden, trägt jedes ausgestellte Zertifikat zwei Adressen: den CRL Distribution Point (CDP) und den Authority Information Access (AIA), unter dem der OCSP-Responder erreichbar ist. Der entscheidende Trick für Hochverfügbarkeit: Diese URLs zeigen nie direkt auf einen einzelnen Server, sondern auf einen DNS-Alias hinter einem Load Balancer – etwa crl.firma.de und ocsp.firma.de.
|
PowerShell # CDP- und AIA-URLs auf HTTP-Aliase setzen (NICHT auf Servernamen!) # Platzhalter wie %3 werden von ADCS automatisch ersetzt certutil -setreg CA\\CRLPublicationURLs "65:http://crl.firma.de/%3%8.crl" certutil -setreg CA\\CACertPublicationURLs "2:http://crl.firma.de/%3%4.crt"
# OCSP-AIA ergaenzen, damit Clients den Responder finden certutil -setreg CA\\CACertPublicationURLs "+32:http://ocsp.firma.de/ocsp"
# Aenderungen aktiv: CA-Dienst neu starten Restart-Service CertSvc |
|---|
|
Warnung · Klassische Falle CDP- oder AIA-URLs, die auf den Hostnamen eines einzelnen Servers zeigen. Diese Adressen werden in jedes ausgestellte Zertifikat fest eingebrannt – und du kannst sie später nicht mehr ändern, ohne neu auszustellen. Steht dann genau dieser eine Server still, scheitert die Sperrprüfung für alle Zertifikate mit dieser URL. Verwende von Anfang an einen DNS-Alias hinter dem Load Balancer, auch wenn dahinter zunächst nur ein Knoten läuft. |
|---|
3. OCSP-Responder-Array hinter dem Load Balancer
ADCS bringt mit der Online Responder Role einen eigenen OCSP-Dienst mit, der sich zu einem Array aus mehreren Knoten zusammenschließen lässt. Die Knoten teilen sich eine gemeinsame Konfiguration über einen Array-Controller und stehen alle hinter dem Alias ocsp.firma.de. Fällt ein Knoten aus, übernimmt der Load Balancer transparent die verbleibenden.
|
PowerShell # Online Responder Role installieren Install-WindowsFeature ADCS-Online-Cert -IncludeManagementTools Install-AdcsOnlineResponder -Force
# Pro Knoten: Erreichbarkeit des OCSP-Endpunkts pruefen certutil -URL http://ocsp.firma.de/ocsp
# Sperrstatus eines konkreten Zertifikats end-to-end verifizieren certutil -verify -urlfetch C:\\Temp\\client.cer |
|---|
Die Revocation Configuration des Responders verweist auf die ausstellende CA und braucht Zugriff auf deren CRL, um Antworten zu erzeugen. Prüfe deshalb, dass jeder OCSP-Knoten die CRL unter dem CDP-Alias tatsächlich erreicht – ein Responder ohne aktuelle CRL liefert sonst veraltete oder gar keine Antworten.
|
Info · Verweis Damit die Sperrinformationen überhaupt aus einer sauber abgesicherten CA kommen, gehört die Online-Ausstellung in eine gehärtete Architektur. Wie du eine Issuing CA und ihre Vorlagen absicherst, zeigt Spoke 3.1 „Auto-Enrollment konfigurieren“ im Zusammenspiel mit der Härtung nach BSI IT-Grundschutz. |
|---|
4. CRL-Intervalle, Delta-CRL und Monitoring
Die CRL hat ein Verfallsdatum – läuft sie ab, bevor eine neue veröffentlicht ist, behandeln viele Clients alle Zertifikate als ungültig. Deshalb gilt: Das Publishing-Intervall deutlich kürzer als die Gültigkeitsdauer wählen, mit großzügigem Überlapp. Eine Delta-CRL ergänzt die Basis-CRL um nur die jüngsten Änderungen und hält so die Datenmenge klein, ohne die Aktualität zu opfern.
|
PowerShell # Basis-CRL: Gueltigkeit 7 Tage, Veroeffentlichung alle 3 Tage (Ueberlapp!) certutil -setreg CA\\CRLPeriodUnits 7 certutil -setreg CA\\CRLPeriod "Days" certutil -setreg CA\\CRLOverlapUnits 4 certutil -setreg CA\\CRLOverlapPeriod "Days"
# Delta-CRL alle 12 Stunden fuer schnelle Aktualitaet certutil -setreg CA\\CRLDeltaPeriodUnits 12 certutil -setreg CA\\CRLDeltaPeriod "Hours"
# CRL sofort neu veroeffentlichen und Verteilung pruefen certutil -CRL |
|---|
|
Praxis-Tipp · Aus dem Beratungsalltag Überwache aktiv das Ablaufdatum der veröffentlichten CRL, nicht nur, ob der Webserver antwortet. Ich habe Ausfälle gesehen, bei denen die Verteilung lief, aber die CRL-Erneuerung wegen eines Rechteproblems still scheiterte – und drei Tage später fiel die halbe Firma auf einmal aus, als die alte CRL ablief. Ein simpler Check „Wie viele Stunden bis CRL-Ablauf?“ warnt dich, bevor die Clients es tun. |
|---|
Praxis-Beispiel: Klinikverbund Sankt Aurelius gGmbH
Der Klinikverbund Sankt Aurelius gGmbH betrieb eine PKI für Smartcard-Logins und Anwendungs-TLS über mehrere Standorte. Die Sperrprüfung lief über einen einzelnen Webserver, dessen Hostname direkt in den CDP-URLs der Zertifikate stand – ein Single Point of Failure, der bei einem Wartungsneustart prompt standortweite Login-Störungen auslöste.
Die Maßnahme: Umstellung der CDP- und AIA-URLs auf die Aliase crl.firma.de und ocsp.firma.de hinter einem Load Balancer, Aufbau eines OCSP-Responder-Arrays aus zwei Knoten und Einführung von Delta-CRLs mit überwachtem Ablaufdatum. Da sich eingebrannte URLs nicht nachträglich ändern lassen, wurde der Wechsel mit der ohnehin anstehenden Neuausstellung der Zertifikate kombiniert.
Das Ergebnis: Wartungsneustarts einzelner Knoten blieben für die Clients unsichtbar, die Sperrprüfung lief durchgehend weiter. Das Monitoring des CRL-Ablaufdatums fing zwei Monate später ein stilles Erneuerungsproblem ab, lange bevor es Nutzer gemerkt hätten.
Verwandte Themen
Häufige Fragen (FAQ)
Brauche ich OCSP, wenn ich schon eine CRL habe?
In der Praxis ja. Moderne Browser und TLS-Stacks bevorzugen OCSP, oft per Stapling, weil es aktueller und sparsamer ist. Die CRL bleibt der robuste Fallback für ältere Clients und den Offline-Fall. Beide zusammen ergeben die belastbare Sperrprüfung – eines allein lässt je nach Client-Landschaft Lücken.
Warum dürfen CDP-URLs nicht auf einen Servernamen zeigen?
Weil diese URLs fest in jedes ausgestellte Zertifikat eingebrannt werden und sich nachträglich nicht mehr ändern lassen, ohne neu auszustellen. Zeigt die URL auf einen einzelnen Server und der fällt aus, scheitert die Sperrprüfung für alle betroffenen Zertifikate. Ein DNS-Alias hinter einem Load Balancer hält dir diese Flexibilität offen.
Was passiert, wenn die CRL abläuft?
Viele Clients behandeln dann sämtliche Zertifikate als nicht prüfbar und damit praktisch als ungültig – TLS-Handshakes und Logins schlagen reihenweise fehl. Deshalb muss das Publishing-Intervall deutlich kürzer sein als die Gültigkeit, mit großzügigem Überlapp, und das Ablaufdatum gehört aktiv überwacht.
Wie viele OCSP-Knoten brauche ich?
Für Hochverfügbarkeit mindestens zwei in einem Responder-Array hinter einem Load Balancer. So übersteht die Sperrprüfung den Ausfall oder Wartungsneustart eines einzelnen Knotens, ohne dass Clients etwas merken. Bei hoher Last oder mehreren Standorten können es entsprechend mehr werden.
Was bringt eine Delta-CRL?
Sie enthält nur die Änderungen seit der letzten Basis-CRL und bleibt dadurch klein, auch wenn die Gesamtliste der Sperrungen wächst. Clients holen sich die kleine Delta-CRL häufig und die große Basis-CRL seltener – das verbessert die Aktualität, ohne die Bandbreite zu belasten.
Wie teste ich, ob die Sperrprüfung wirklich funktioniert?
Mit Bordmitteln: certutil -URL öffnet eine GUI zum Prüfen von CDP- und OCSP-Erreichbarkeit, und certutil -verify -urlfetch zieht alle Sperrinformationen für ein konkretes Zertifikat live und zeigt das Ergebnis der Kettenprüfung. Damit verifizierst du end-to-end, dass CRL und OCSP tatsächlich antworten.
Nächste Schritte mit boddenberg.de
Hochverfügbare Sperrprüfung ist eines der Themen, die im Normalbetrieb unsichtbar sind – und im Störfall die ganze Firma lahmlegen. Drei Wege, wie ich dich unterstütze:
Schick mir eine kurze Mail mit deinem Szenario, und du bekommst innerhalb eines Werktags eine Einschätzung, wo deine Sperrprüfung am verwundbarsten ist.
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund