certmon.de EN

Sperrliste abgelaufen: Notfallplan für die Microsoft-PKI

Läuft die Sperrliste (CRL) einer CA ab, können Clients nicht mehr prüfen, ob Zertifikate dieser CA gesperrt sind – und lehnen sie ab. Auf einen Schlag fallen WLAN mit 802.1X, VPN, Smartcard-Anmeldung, LDAPS oder interne Webseiten aus. Besonders tückisch ist die Offline-Root: Ihre Sperrliste ist oft ein halbes Jahr oder länger gültig, und niemand erinnert sich an den Termin.

Typische Symptome

  • Fehler 0x80092013 („Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war“)
  • Smartcard- bzw. Windows-Hello-Anmeldung meldet, der Sperrstatus des Domänencontrollerzertifikats könne nicht bestimmt werden
  • NPS lehnt WLAN- und VPN-Anmeldungen ab, im Ereignisprotokoll mit Hinweis auf die Sperrprüfung

1. Herausfinden, welche Sperrliste abgelaufen ist

Exportieren Sie ein betroffenes Zertifikat (z. B. das eines Servers) als .cer und lassen Sie Windows die komplette Kette samt Sperrlisten abrufen:

certutil -verify -urlfetch C:\temp\server.cer

Die Ausgabe zeigt für jede CA der Kette die abgerufenen Sperrlisten-URLs und ob sie gültig sind. Eine einzelne CRL-Datei prüfen Sie direkt – die Zeile NextUpdate ist das Ablaufdatum:

Invoke-WebRequest http://pki.firma.de/CertEnroll/FIRMA-ROOT-CA.crl -OutFile $env:TEMP\root.crl
certutil $env:TEMP\root.crl

2. Ausstellende CA (online): neu veröffentlichen

Auf der ausstellenden CA als Administrator:

certutil -crl

Das erzeugt neue Base- und Delta-Sperrlisten und legt sie an allen konfigurierten Orten ab (AD, C:\Windows\System32\CertSrv\CertEnroll, ggf. Dateifreigabe des Webservers). Schlägt das fehl, läuft meist der Dienst „Active Directory-Zertifikatdienste“ nicht, oder die CA hat keine Schreibrechte auf die Freigabe des Webservers (das Computerkonto der CA braucht Ändern-Rechte). Die Veröffentlichungsorte sehen Sie in certsrv.msc → Eigenschaften der CA → Erweiterungen.

3. Offline-Root: neue Sperrliste signieren und verteilen

  1. Root-CA starten und Uhrzeit prüfen – eine falsche Systemzeit erzeugt eine Sperrliste mit falschem Gültigkeitszeitraum.
  2. Neue Sperrliste erstellen: certutil -crl
  3. Die Datei aus C:\Windows\System32\CertSrv\CertEnroll\ per USB-Stick auf die ausstellende CA oder einen Admin-Rechner kopieren.
  4. Im AD veröffentlichen – der letzte Parameter ist der Rechnername der Root-CA (der Container unter CDP im AD): 
    certutil -dspublish -f "C:\temp\FIRMA-ROOT-CA.crl" ROOTCA01
  5. Auf den Webserver kopieren, von dem die Clients per HTTP laden (die URL steht in den CA-Zertifikaten unter „Sperrlisten-Verteilungspunkte“).
  6. Root-CA wieder herunterfahren.

4. Clients schneller zum Umdenken bringen

Clients speichern Sperrlisten zwischen. Eine abgelaufene Liste laden sie zwar von selbst neu, auf wichtigen Servern können Sie aber nachhelfen:

certutil -urlcache crl delete
certutil -setreg chain\ChainCacheResyncFiletime @now

# NPS-Server (WLAN/VPN): Dienst neu starten
Restart-Service IAS

5. Den nächsten Ausfall verhindern

  • Laufzeit der Root-Sperrliste großzügig wählen und eine Überlappung einplanen, z. B. ein Jahr mit vier Wochen Überlappung. Auf der Root-CA: 
    certutil -setreg CA\CRLPeriodUnits 1
certutil -setreg CA\CRLPeriod "Years"
certutil -setreg CA\CRLOverlapUnits 4
certutil -setreg CA\CRLOverlapPeriod "Weeks"
Restart-Service certsvc
certutil -crl
  • Termin eintragen: das NextUpdate der Root-Sperrliste minus einige Wochen, mit Verweis auf diese Anleitung.
  • Alle Veröffentlichungsorte prüfen: Sperrlisten liegen oft doppelt (AD und HTTP) – und nach Umzügen auch veraltet an Orten, die niemand mehr kennt.

Genau das prüft der kostenlose ADCS Health Check: Ablauf und Aktualität aller Sperrlisten im AD und per HTTP, veraltete Kopien, fehlende Objekte und die Offline-Root-CRL – mit Ampel und konkreten Befehlen im Report.

Weitere Ratgeber