Abgelaufene Sperrliste (CRL) einer Windows-CA erkennen und beheben

Freitagmorgen, 8 Uhr: Die Smartcard-Anmeldung scheitert, das VPN verbindet nicht, das WLAN lehnt jedes Notebook ab, LDAPS und interne HTTPS-Seiten melden Zertifikatfehler. Alles gleichzeitig. Die Zertifizierungsstelle läuft trotzdem. Willkommen bei der abgelaufenen Sperrliste – einem der teuersten Kalenderfehler in einer Windows-PKI.

Wie die Sperrprüfung funktioniert

Prüft Windows ein Zertifikat, baut es die Kette bis zur Root-CA auf und prüft jedes Glied gegen die Sperrliste (Certificate Revocation List, CRL) seiner ausstellenden CA. Wo diese Liste liegt, steht im Zertifikat als CRL Distribution Point (CDP), meist per HTTP und LDAP.

Das Zertifikat der ausstellenden CA wird also gegen die CRL der Root-CA geprüft. Läuft genau diese eine Datei ab, sind alle Zertifikate unterhalb der Root-CA auf einen Schlag betroffen. Für Windows ist der Sperrstatus dann unbekannt, und Dienste wie Smartcard-Anmeldung oder NPS werten das als Fehler – obwohl kein einziges Zertifikat gesperrt ist.

Die Spanne zwischen Next CRL Publish und Next Update ist die Überlappung. Ohne eigenen Wert sind das 10 Prozent der CRL-Gültigkeit, höchstens aber 12 Stunden. Einstellbar über CRLOverlapUnits und CRLOverlapPeriod.

Typische Auslöser

• Die CRL der Offline-Root-CA (oft 6 oder 12 Monate gültig) wurde nicht rechtzeitig neu signiert
• Die neue Root-CRL liegt nur auf der Root-CA, nicht an allen CDPs
• Ein HTTP-CDP ist nicht erreichbar oder der LDAP-CDP enthält noch die alte Datei
• Die Delta-CRL der ausstellenden CA ist abgelaufen oder fehlt am angegebenen Ort

Diagnose: Welche CRL ist das Problem?

1. Kette mit Abruf prüfen

Der wichtigste Befehl. Er lädt alle AIA-Zertifikate und CDP-Sperrlisten frisch aus dem Netz. Jeder dwErrorStatus ungleich 0 ist ein echter Fehler.

certutil -f -urlfetch -verify C:\ISW\server.cer
certutil -t 30000 -f -urlfetch -verify C:\ISW\server.cer

2. CDPs einzeln abrufen und CRL auslesen

certutil -URL öffnet das „URL Retrieval Tool“ und ruft alle HTTP- und LDAP-Adressen ab. Mit certutil -dump sieht man Next Update und Next CRL Publish der Datei.

certutil -URL C:\ISW\server.cer
certutil -split -URL http://pki.contoso.com/pki/ContosoRootCA.crl
certutil -dump C:\Windows\System32\CertSrv\CertEnroll\ContosoRootCA.crl

3. Enterprise PKI (PKIView)

pkiview.msc prüft jede AIA- und CDP-Adresse aller CAs. „OK“ ist gut, „Expiring“ ist die letzte freundliche Warnung, „Unable to Download“ heißt: falsch konfiguriert oder Datei nicht kopiert.

4. CAPI2-Protokoll

Microsoft-Windows-CAPI2/Operational protokolliert jede Kettenprüfung. Es ist standardmäßig aus. Eine abgelaufene CRL erkennt man am Ereignis „CertRejectedRevocationInfo“ mit der Aktion „CheckTimeValidity“.

wevtutil sl Microsoft-Windows-CAPI2/Operational /e:true
wevtutil sl Microsoft-Windows-CAPI2/Operational /ms:4194304
Get-WinEvent -LogName 'Microsoft-Windows-CAPI2/Operational' -MaxEvents 2000 |
  Where-Object { $_.ToXml() -match 'CheckTimeValidity' } |
  Select-Object TimeCreated, Id, TaskDisplayName

Beheben: CRL neu signieren und überall verteilen

1. Offline-Root-CA hochfahren und die Systemzeit prüfen.
2. Neue CRL mit certutil -crl erzeugen und mit certutil -dump kontrollieren.
3. Datei auf alle HTTP-CDPs kopieren – exakt mit dem Namen aus der CDP-Adresse.
4. CRL mit certutil -dspublish ins Active Directory veröffentlichen.
5. CRLs und Delta-CRL der ausstellenden CA prüfen und bei Bedarf neu veröffentlichen.
6. Caches auf DCs, NPS, VPN- und LDAPS-Servern leeren.

# 1.–2. auf der Offline-Root-CA
certutil -crl
copy C:\Windows\System32\CertSrv\CertEnroll\*.cr* E:\

# 3. HTTP-CDP
copy E:\ContosoRootCA.crl \\WEB1\pki

# 4. LDAP-CDP (Container = Computername der Root-CA)
certutil -dspublish -f E:\ContosoRootCA.crl ORCA1

# 6. auf prüfenden Systemen
certutil -urlcache * delete
certutil -setreg chain\ChainCacheResyncFiletime @now

# Kontrolle
certutil -f -urlfetch -verify C:\ISW\server.cer

Danach muss PKIView überall „OK“ zeigen. Die LDAP-Veröffentlichung braucht noch die AD-Replikation zu allen DCs. Anschließend die Root-CA wieder herunterfahren und verwahren.

Notbremse für NPS, wenn die Root-CA nicht greifbar ist

Für EAP-TLS auf dem NPS dokumentiert Microsoft DWORD-Werte unter HKLM\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 (Standard 0). IgnoreRevocationOffline = 1 lässt Clients zu, wenn der Server mit der CRL nicht erreichbar ist. NoRevocationCheck = 1 schaltet die Sperrprüfung komplett ab.

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13' `
  -Name IgnoreRevocationOffline -PropertyType DWord -Value 1 -Force

Für die Smartcard-Anmeldung gibt es diese Abkürzung nicht: Laut Microsoft lässt sich die Sperrprüfung der eingebauten Prüfanbieter nicht abschalten.

Fallstricke

Vorbeugen und Compliance

• Kalendereintrag für die Root-CRL mindestens 30 Tage vor Next Update, mit Vertretung
• Next Update aller CRLs an allen CDPs täglich überwachen und vor Ablauf alarmieren
• PKIView regelmäßig ansehen, „Expiring“ ernst nehmen
• Kopierjobs der ausstellenden CA auf Webserver mit Fehlermeldung ausstatten
• Zugang zur Offline-Root-CA (Kennwort, HSM, Standort) für mindestens zwei Personen dokumentieren
• Den Ablauf für Signieren und Verteilen der Root-CRL schriftlich festhalten

Das zahlt direkt auf die Anforderungen ein: BSI IT-Grundschutz CON.1 (Kryptokonzept) und DER.4 (Notfallmanagement) sowie NIS2 Art. 21 Abs. 2 lit. c (Aufrechterhaltung des Betriebs) und lit. h (Kryptografie).

Fazit

Eine abgelaufene CRL ist kein Zertifikatsproblem, sondern ein Terminproblem. Wer neu startet oder neu ausstellt, verliert Zeit und riskiert die ausstellende CA. Wer die Root-CA greifbar hat und alle CDPs kennt, ist in 30 bis 90 Minuten wieder online.