AD CS CRL Monitoring 2026 ist für viele Windows-Unternehmen ein unterschätzter Stabilitätsfaktor. Eine interne Certification Authority stellt Zertifikate für Server, Benutzer, VPN und andere Dienste aus. Damit diese Zertifikate zuverlässig geprüft werden können, müssen Vertrauenskette und Sperrstatus erreichbar und aktuell sein. Fällt die Zertifikatssperrliste (Certificate Revocation List, CRL) aus oder ist ihre Aktualität überschritten, können Anwendungen langsam reagieren oder Zertifikatsprüfungen fehlschlagen. Microsoft dokumentiert ausdrücklich, dass fehlerhafte CDP-Adressen zu Störungen bei VPN, Smartcard-Anmeldung und digitalen Signaturen führen können. Dieser Leitfaden zeigt den Unterschied zwischen Root- und Issuing-CA, Base- und Delta-CRL, HTTP- und HTTPS-Distribution und die geeigneten Tests und Alarmierungen.
Autor: Salman Dolatpanah Gortlar · GORTNET · Stand 5. November 2026
Kernaussage: Der Client muss eine aktuelle, signierte CRL am eingebetteten CDP erreichen können. Ein generierter Datensatz auf der CA reicht nicht aus.
AD CS CRL Monitoring 2026: Wozu eine Sperrliste gebraucht wird
Ein X.509-Zertifikat besitzt eine Gültigkeitsdauer. Es kann aber bereits vor dem Ablauf unzuverlässig werden, etwa wenn der private Schlüssel kompromittiert oder eine Identität nicht mehr zulässig ist. Eine Certificate Authority kann dieses Zertifikat widerrufen. Die Information wird über eine signierte Sperrliste veröffentlicht, die Clients anhand eines definierten Distribution Points abrufen.
Ein gültiges Ablaufdatum genügt daher nicht, um ein Zertifikat als vertrauenswürdig zu behandeln. Die Prüfung muss je nach Anwendung auch die relevanten Sperrinformationen berücksichtigen. Gleichzeitig kann ein Client die aktuelle Liste nur verwenden, wenn er den vorgesehenen Endpunkt tatsächlich erreicht. Ein sauber dokumentierter CRL-Pfad schützt damit sowohl die Sicherheit als auch die Zuverlässigkeit verschiedener Unternehmensdienste.
CDP und AIA: Zwei unterschiedliche PKI-Funktionen
Der CRL Distribution Point (CDP) verweist auf Stellen, an denen Sperrinformationen verfügbar sind. Authority Information Access (AIA) kann unter anderem auf Informationen über die ausstellende CA oder bestimmte Validierungsdienste hinweisen. Beide Erweiterungen werden beim Ausstellen in Zertifikate eingebettet. Eine nachträgliche Änderung der CA-Konfiguration passt bereits verteilte Zertifikate nicht automatisch an.
Deshalb sollten CDP- und AIA-Adressen vor einem großen Zertifikatsrollout geplant werden. Ein Zertifikat, das eine veraltete interne URL enthält, kann diese noch Jahre später verwenden. Halten Sie frühere Endpunkte während einer kontrollierten Übergangszeit erreichbar, soweit sie für bestehende Zertifikate benötigt werden. Ein neuer DNS-Name allein korrigiert keine bereits im Zertifikat festgehaltene Adresse.
Root CA und Issuing CA separat betrachten
In einer hierarchischen PKI ist die Root CA häufig besonders geschützt und möglicherweise offline. Darunter stellen untergeordnete CAs die eigentlichen Server- oder Benutzerzertifikate aus. Die CRL einer Offline-Root-CA wird oft deutlich seltener veröffentlicht, während Issuing-CAs je nach Anforderungen kürzere Intervalle und Delta-CRLs nutzen können. Ein universelles Veröffentlichungsintervall ist nicht für jede Architektur geeignet.
Überwachen Sie Root- und Sub-CA getrennt. Eine länger gültige Root-CRL ist nicht automatisch gefährlich, solange der geplante Sicherheits- und Veröffentlichungsprozess eingehalten wird. Entscheidend ist, dass eine neue signierte Liste vor Ablauf der bisherigen verfügbar ist. Für offline betriebene Root-CAs benötigt der Prozess feste Verantwortliche, eine sichere Dateiübertragung und einen unabhängig überprüften Distribution Point.
Base CRL und Delta CRL unterscheiden
Eine Base CRL enthält den maßgeblichen Sperrstatus für die ausstellende CA. Eine Delta CRL enthält zwischenzeitliche Änderungen und wird zusammen mit der passenden Basisliste verwendet. Delta-CRLs können bei größeren Umgebungen die Aktualisierung beschleunigen. Sie sind allerdings kein Ersatz für die zugehörige gültige Base CRL. Die Intervalle müssen zum erwarteten Widerrufsbedarf und der vorhandenen Infrastruktur passen.
Prüfen Sie bei der Veröffentlichung die Abhängigkeiten beider Dateien. Ein aktueller Delta-Eintrag auf dem Webserver hilft nicht, wenn die Base CRL bereits abgelaufen oder nicht erreichbar ist. Planen Sie genügend zeitlichen Überlapp für Generierung, Kopieren, Replikation und clientseitigen Abruf. Störfälle entstehen häufig nicht bei der CA selbst, sondern irgendwo auf dem Weg zum abrufenden Client.
Warum HTTP für CRL-Distribution sinnvoll sein kann
Ein häufiger Reflex lautet, jede Sicherheitsdatei ausschließlich über HTTPS bereitzustellen. Bei CRL-Distribution ist die Situation differenzierter. Sperrlisten sind durch die CA digital signiert, sodass ihre Integrität kryptografisch geschützt wird. Der Abruf über HTTPS kann wiederum eine zusätzliche Zertifikatsprüfung auslösen, die selbst vom Abruf einer CRL abhängt. Das kann zirkuläre Abhängigkeiten erzeugen.
Microsoft empfiehlt in bestimmten Szenarien, etwa für Microsoft Entra certificate-based authentication, ausdrücklich einen hochverfügbaren HTTP-Endpunkt für die Sperrliste. Das bedeutet nicht, dass alle administrativen PKI-Schnittstellen über ungeschütztes HTTP erreichbar sein sollen. Schreibende Veröffentlichung, CA-Management und private Schlüssel müssen weiterhin strikt geschützt sein. Der lesende CRL-Endpunkt hat eine andere Sicherheitsfunktion als die administrative Oberfläche.
HTTPS und Port 443: Wann es trotzdem funktioniert
Ein HTTPS-CDP ist nicht pauschal verboten. Ob er zuverlässig funktioniert, hängt von Clientverhalten, verwendeten Zertifikaten, Abhängigkeiten und der konkreten PKI-Architektur ab. Bei bestimmten Clients kann eine HTTPS-Verbindung funktionieren, während sie bei anderen Verzögerungen oder Fehler auslöst. Aus Sicherheitsgründen dürfen Administratoren deshalb weder den Wechsel auf HTTPS blind erzwingen noch jeden HTTP-CDP pauschal als Schwachstelle einstufen.
Prüfen Sie die Microsoft-Dokumentation zum betroffenen Szenario und testen Sie reale Clients. Besonders relevant sind Nicht-Windows-Systeme, Applikationsserver, VPN-Gateways und unterschiedliche Zertifikatsketten. Für bestehende Zertifikate kann außerdem die ursprüngliche CDP-URL weiterhin relevant sein. Eine erfolgreiche Browseranzeige allein beweist nicht, dass die vollständige Widerrufsprüfung in der Fachanwendung funktioniert.
Veröffentlichung und tatsächliche Auslieferung getrennt prüfen
Eine CA kann eine neue CRL erzeugen, ohne dass sie bereits am vorgesehenen Webserver angekommen ist. Zwischen Generierung und Abruf stehen möglicherweise Dateikopien, Webserver, DNS und Firewallregeln. Microsoft empfiehlt daher, die gesamte Zustellkette zu überwachen. Das Ziel ist nicht bloß „CRL Published“, sondern die korrekte Datei am tatsächlichen Endpunkt aus Sicht eines relevanten Clients.
Prüfen Sie Dateinamen, Erreichbarkeit und die für CRL-Dateien erforderliche Webserverkonfiguration. Der HTTP-Endpunkt muss die Datei vollständig und ohne ungewollte Authentifizierungsanforderung liefern, sofern dies zum Design gehört. Bewahren Sie die Berechtigungen der schreibenden Veröffentlichungsidentität strikt getrennt vom lesenden Abruf. Eine öffentlich lesbare signierte Sperrliste ist etwas anderes als eine öffentlich beschreibbare PKI-Ablage.
Next Update und Warnschwellen sinnvoll überwachen
Zertifikatssperrlisten enthalten Angaben zur Gültigkeit, insbesondere This Update und Next Update. Das Monitoring sollte rechtzeitig warnen, bevor die aktive CRL ihre nächste Aktualisierungsgrenze erreicht. Der passende Vorlauf hängt von Veröffentlichungsintervall, Überlapp, Replikationsdauer und Bereitschaftsorganisation ab. Ein fester Grenzwert von wenigen Stunden kann bei einer offline betriebenen Root CA viel zu spät sein.
Ergänzen Sie neben der Datumsprüfung ein Monitoring des tatsächlichen HTTP-Abrufs. Eine gültige lokale CRL-Datei auf der CA ist wertlos, wenn der Client-URL-Pfad nicht funktioniert. Nutzen Sie unterschiedliche Schweregrade und benennen Sie für jede CA den zuständigen Betreiber. Ein Alarm sollte klar zeigen, welche Liste, welcher Endpunkt und welche Frist betroffen sind.
Certutil zur technischen Kontrolle einsetzen
Windows bietet mit certutil Werkzeuge zur Prüfung von Zertifikaten und Sperrlisten. Beispielsweise lassen sich CRL-Dateien auslesen und die enthaltenen Aktualisierungszeiten kontrollieren. Auch die Überprüfung einer Zertifikatskette mit Online-Abruf kann zur Diagnose beitragen. Die genaue Befehlsfolge sollte zur Zertifikatsart und zum Prüfziel passen und zunächst auf einem Testsystem erprobt werden.
Dokumentieren Sie die geprüfte Zertifikatskette, den tatsächlichen CDP und den Zeitpunkt der Messung. Ein Test ausschließlich auf der CA kann Netzprobleme für entfernte Clients verdecken. Prüfen Sie deshalb mindestens einen repräsentativen Windows- und gegebenenfalls Linux-Client sowie VPN- oder Applikationsserver, die den Endpunkt verwenden. Eine kleine Testmatrix erspart viele Stunden bei späteren TLS- und Anmeldeproblemen.
CRL-Caching und Erstverbindungs-Latenz
Clients können CRLs zwischenspeichern. Dadurch kann die erste Zertifikatsprüfung deutlich langsamer sein als nachfolgende Verbindungen, insbesondere wenn ein Abrufpfad langsam oder nicht erreichbar ist. Dieses Verhalten ist ein möglicher Hinweis auf Probleme mit Zertifikatsketten oder Sperrlisten, aber nicht jeder langsame TLS-Handshake beruht automatisch darauf. DNS, TCP, TLS und Applikationsstart müssen getrennt gemessen werden.
Vergleichen Sie den Zeitbedarf vor und nach einem kontrollierten CRL-Abruf sowie den Status des tatsächlichen Distribution Points. Protokollieren Sie die Ergebnisse ohne riskante Änderungen am CA-Produktionsbetrieb. Eine schnellere Verbindung nach dem Veröffentlichen einer CRL ist ein starkes Indiz, ersetzt aber nicht den Nachweis, dass alle relevanten Endpunkte künftig erreichbar bleiben.
CDP-Umstellung ohne ungültige Zertifikate
Microsoft empfiehlt für Änderungen an Distribution Points einen gestuften Übergang. Zuerst wird der neue Endpunkt vorbereitet und geprüft. Danach kann er für neu ausgestellte Zertifikate verwendet werden. Bestehende Zertifikate benötigen ihre ursprünglichen CDP-Adressen weiterhin, solange sie gültig und im Einsatz sind. Ein abruptes Entfernen des alten Webservers kann deshalb zu unerwarteten Fehlern führen.
Planen Sie DNS, Firewallregeln, Zertifikatserneuerung und Veröffentlichungsprozess gemeinsam. Halten Sie einen dokumentierten Rückfallweg bereit und stimmen Sie Änderungen mit den betroffenen Anwendungsteams ab. Vor allem PKI-Änderungen sollten nicht gleichzeitig mit anderen großen Netzänderungen erfolgen, wenn sich Fehler sonst nur schwer zuordnen lassen. Testen Sie nach der Umstellung neue und bereits ausgestellte Zertifikate.
Monitoring mit Zabbix und Alarmierung
Eine zentrale Überwachung kann die Erreichbarkeit der HTTP-Endpunkte, die verbleibende CRL-Gültigkeit und den Status der CA-Dienste erfassen. Besonders hilfreich ist die Kombination aus serverseitiger Veröffentlichung und clientseitigem Downloadtest. Je nach Umgebung lassen sich die Ergebnisse über Zabbix mit E-Mail- oder Push-Benachrichtigungen an die zuständigen Administratoren übermitteln.
Vermeiden Sie einen Alarm, der erst nach Ablauf der CRL ausgelöst wird. Definieren Sie Warning und Critical mit ausreichend Vorlauf sowie eine Eskalation für Wochenenden und Feiertage. Dokumentieren Sie, wer eine neue Sperrliste signiert, wer die Verteilung übernimmt und wer die Funktionsprüfung abnimmt. Das Monitoring sollte außerdem das Ausbleiben von Messwerten als eigenes Problem erkennen.
30-Tage-Plan für PKI-Revocation-Health
Woche eins: Root- und Issuing-CAs, Zertifikatsketten, CRL-Intervalle, CDP- und AIA-Endpunkte inventarisieren. Woche zwei: Erreichbarkeit und Dateien von mehreren Clientnetzen prüfen. Woche drei: Ablaufwarnungen und die verantwortliche Alarmkette einrichten. Woche vier: Eine kontrollierte Neuveröffentlichung mit vollständiger End-to-End-Prüfung üben und den Wiederanlauf dokumentieren.
Das Ziel ist ein nachvollziehbarer Nachweis, dass Widerrufsinformationen rechtzeitig erstellt, sicher verteilt und von allen wichtigen Clients verarbeitet werden können. Diese Zuverlässigkeit verbessert sowohl die PKI-Sicherheit als auch die Verfügbarkeit von VPN, Mail, Webdiensten und digitalen Signaturen.
Häufige Fragen zu AD CS CRL Monitoring 2026
Ist HTTP für CRL-Dateien grundsätzlich unsicher?
Nicht pauschal. CRLs sind kryptografisch signiert und Microsoft empfiehlt für bestimmte Revocation-Szenarien ausdrücklich hochverfügbare HTTP-Endpunkte.
Warum kann HTTPS-CDP Probleme verursachen?
Weil die Validierung der HTTPS-Verbindung selbst eine Zertifikats- und möglicherweise eine Sperrlistenprüfung auslösen kann.
Warum reicht eine neue CRL auf der Root CA nicht aus?
Weil die Datei auch am tatsächlichen Client-Endpunkt verfügbar sein muss.
Kann ich alte CDP-URLs sofort löschen?
Nein. Bereits ausgestellte Zertifikate können diese Adressen weiterhin referenzieren.
Was sollte Zabbix prüfen?
Next Update, tatsächliche Erreichbarkeit, korrekte Dateiversion und den Zustand der Veröffentlichungs- und Abrufkette.
Fazit: Eine PKI ist nur so zuverlässig wie ihre Sperrinformationen
AD CS CRL Monitoring 2026 gehört zur laufenden Serverüberwachung. Entscheidend sind die sichere Veröffentlichung, verfügbare CDP-Endpunkte und Warnungen vor dem Ablauf der Liste. Klare Zuständigkeiten helfen, vermeidbare TLS- und Anmeldeausfälle zu verhindern.
Weiterführende GORTNET-Artikel
Für eine Überprüfung von PKI, CRL und Zertifikatsketten GORTNET kontaktieren.
Offizielle Microsoft-Quellen
- Microsoft: AD CS PKI Design Considerations
- Microsoft: Revoke Certificates and Publish CRLs
- Microsoft: Entra Certificate Revocation Lists
Stand 5. November 2026. Anforderungen an CRL-Endpunkte hängen von Anwendung, Clients und PKI-Design ab.