CRL vs. ARL: Warum beide in der PKI wichtig sind

Kurz gesagt: Eine Zertifikatssperrliste (CRL) veröffentlicht den Sperrstatus von Endbenutzerzertifikaten, die an Benutzer, Server und Geräte ausgestellt wurden, während eine Zertifizierungsstellensperrliste (ARL) den Sperrstatus von Zertifizierungsstellenzertifikaten innerhalb der Vertrauenshierarchie selbst veröffentlicht. Beide verwenden das gleiche RFC-5280-Format, doch ein versäumtes ARL-Update hat weitaus gravierendere Folgen: Es kann dazu führen, dass eine gesamte Zertifizierungsstelle kompromittiert wird und alle von ihr jemals ausgestellten Zertifikate fälschlicherweise als vertrauenswürdig eingestuft werden.

Jedes digitale Zertifikat hat ein Ablaufdatum, doch ein Zertifikat muss dieses Datum nicht erreichen, um seine Vertrauenswürdigkeit zu verlieren. Kompromittierte private Schlüssel, organisatorische Änderungen, Fehlkonfigurationen der Zertifizierungsstelle und Sicherheitsvorfälle können ein Zertifikat weit vor seinem geplanten Ablaufdatum ungültig machen. Die PKI-Infrastruktur muss daher über einen zuverlässigen Mechanismus verfügen, um diese Ungültigmachung an alle vertrauenden Systeme zu kommunizieren.

Dieser Mechanismus ist der Zertifikatswiderruf, der innerhalb der X.509 Public Key Infrastructure auf zwei Ebenen operiert. Eine Zertifikatssperrliste (CRL) kommuniziert den Widerruf von Endbenutzerzertifikaten, also Zertifikaten, die an Benutzer, Server und Geräte ausgestellt wurden. Eine Zertifizierungsstellensperrliste (CA-Sperrliste) kommuniziert den Widerruf von CA-Zertifikaten, also Zertifikaten, die an die Zertifizierungsstellen innerhalb der Vertrauenshierarchie ausgestellt wurden.

Diese Unterscheidung ist operativ relevant, da die Konsequenzen auf den beiden Ebenen grundlegend unterschiedlich sind. Ein einzelnes widerrufenes Endbenutzerzertifikat betrifft eine einzelne Identität oder einen einzelnen Dienst. Ein widerrufenes Zertifizierungsstellenzertifikat kann hingegen alle jemals von dieser Zertifizierungsstelle ausgestellten Zertifikate ungültig machen und potenziell Tausende von Identitäten in der gesamten PKI-Umgebung einer Organisation betreffen.

Um zu verstehen, wie die einzelnen Listen funktionieren, wo sie sich unterscheiden und wo Unternehmensumgebungen am häufigsten Schwächen aufweisen, muss man mit der PKI-Hierarchie beginnen, die beiden Listen ihren Kontext gibt.

Direkt zu: Zusammenfassung | Wichtigste Erkenntnisse | Kurzcheckliste | Vergleichstabelle | Entscheidungstabelle | Verantwortlichkeits-/Aktionsmatrix | Nächste Schritte | FAQ

Executive Summary

CRL und ARL verwenden zwar das gleiche RFC-5280-Format, dienen aber unterschiedlichen Ebenen der PKI-Vertrauenshierarchie: Eine CRL widerruft Endbenutzerzertifikate, während eine ARL CA-Zertifikate und damit alle unterhalb der betroffenen CA ausgestellten Zertifikate widerruft. PKI-Teams in Unternehmen verwalten CRLs in der Regel gut, vernachlässigen jedoch häufig die Veröffentlichung von ARLs. Dadurch fehlt ein formaler Mechanismus zum Widerruf kompromittierter Zwischenzertifizierungsstellen. Diese Lücke gewinnt mit steigendem Zertifikatsvolumen und häufigeren Widerrufsprüfungen zunehmend an Bedeutung: Laut der DigiCert Trust Pulse Survey vom Juli 2025 hatten 45 % der Unternehmen im vergangenen Jahr zertifikatsbedingte Ausfallzeiten, wobei 37.5 % auf abgelaufene oder nicht korrekt validierte Zertifikate zurückzuführen waren. Die Umstellung des CA/Browser Forums auf 47-Tage-TLS-Zertifikate bis März 2029 bedeutet, dass die Widerrufsinfrastruktur deutlich häufigeren Ausstellungs- und Validierungszyklen standhalten muss. Dieser Leitfaden behandelt die PKI-Vertrauenshierarchie, die Funktionsweise von CRL und ARL, die häufigsten Schwachstellen in Unternehmen, eine Entscheidungstabelle zur Überwachung von Widerrufen und die nächsten Schritte für PKI-, Sicherheits-, Plattform- und Compliance-Teams.

Wichtige Erkenntnisse

• Eine CRL listet widerrufene Endbenutzerzertifikate auf; eine ARL listet widerrufene CA-Zertifikate auf. Beide verwenden dasselbe RFC-5280-Format und unterscheiden sich durch das Flag „onlyContainsCACerts“ in der Erweiterung „Issuing Distribution Point“.
• Ein fehlender CRL-Eintrag betrifft ein einzelnes Zertifikat. Ein fehlender ARL-Eintrag kann dazu führen, dass eine gesamte Zertifizierungsstelle kompromittiert wird und alle von ihr jemals ausgestellten Zertifikate fälschlicherweise als vertrauenswürdig eingestuft werden.
• Bei vielen internen PKI-Implementierungen wird eine ARL überhaupt nicht veröffentlicht, da davon ausgegangen wird, dass eine Root-CA niemals eine Intermediate-CA widerrufen muss.
• Bei Ausfällen von Verteilungspunkten kommt es häufiger zu einem offenen als zu einem geschlossenen Ausfall, was bedeutet, dass die Widerrufsprüfung stillschweigend ausfallen kann, ohne eine Warnung auszulösen.

Schnelle Checkliste

• Vergewissern Sie sich, dass tatsächlich eine ARL für Ihre Root-CA veröffentlicht ist, und gehen Sie nicht einfach davon aus, dass dies unnötig ist.
• Prüfen Sie die Gültigkeitsdauer Ihrer ARL; mehrere Monate oder länger führen zu einem verlängerten Expositionsfenster, falls eine Intermediate CA kompromittiert wird.
• Prüfen Sie, ob die Verfügbarkeit der CRL- und ARL-Verteilungspunkte aktiv überwacht wird und nicht nur als erreichbar angenommen wird.
• Testen Sie den gesamten Widerrufsprozess mindestens einmal während eines PKI-Auditzyklus, nicht nur bei der Zertifikatsausstellung und -erneuerung.
• Halten Sie eine aktuelle Liste der Systeme bereit, die Zertifikate der einzelnen Zwischenzertifizierungsstellen besitzen, damit Sie die potenziellen Auswirkungen vor dem Widerruf abschätzen können.

Die PKI-Vertrauenshierarchie

Die Public-Key-Infrastruktur (PKI) ist als hierarchische Vertrauenskette organisiert. An der Spitze dieser Hierarchie steht eine Root-Zertifizierungsstelle (Root-CA) und dient als oberste Vertrauensinstanz. Die Root-CA stellt Zertifikate an eine oder mehrere Intermediate- oder Subordinate-CAs aus, die wiederum Zertifikate an Endbenutzer, Server, Netzwerkgeräte und Anwendungen vergeben.

Die Root-Zertifizierungsstelle (Root CA) wird üblicherweise in einer abgeschotteten Offline-Umgebung betrieben, um ihren privaten Schlüssel vor unbefugtem Zugriff zu schützen. Da sie nicht an der routinemäßigen Zertifikatsausstellung beteiligt ist, besteht ihre Hauptaufgabe darin, untergeordnete Intermediate CAs zu zertifizieren und, falls erforderlich, diese Zertifizierungen zu widerrufen, wenn eine Intermediate CA kompromittiert oder als unzuverlässig eingestuft wird.

Vertrauen ist in diesem Modell transitiv. Wenn eine vertrauende Partei ein Serverzertifikat validiert, erstellt sie eine Zertifikatskette vom Endbenutzerzertifikat über alle Zwischenzertifizierungsstellen bis zur Stammzertifizierungsstelle. Jedes Glied dieser Kette wird kryptografisch verifiziert, und Vertrauen wird nur dann akzeptiert, wenn die gesamte Kette erfolgreich bis zu einer Stammzertifizierungsstelle validiert werden kann, der das vertrauende System bereits vertraut.

Diese hierarchische Vererbung von Vertrauen macht den Widerruf von Zertifikaten auf Zertifizierungsstellenebene so wichtig. Ein Kompromiss auf der Ebene der Zwischenzertifizierungsstelle wirkt sich auf alle von dieser Zertifizierungsstelle ausgestellten Zertifikate aus und macht den Widerruf somit zu einer der folgenreichsten Operationen im PKI-Management. Die Zertifikatssperrliste (CRL) und die Autorisierungssperrliste (ARL) erfüllen jeweils eine definierte Rolle innerhalb dieser Hierarchie, und ihr separates Verständnis erleichtert den Vergleich ihrer Unterschiede.

Sperrliste für Zertifikate

Eine Zertifikatssperrliste (CRL) ist eine digital signierte Datenstruktur, die von einer Zertifizierungsstelle veröffentlicht wird, um den Sperrstatus der von ihr ausgestellten Endbenutzerzertifikate zu kommunizieren. Jeder Eintrag in einer CRL identifiziert ein gesperrtes Zertifikat anhand seiner Seriennummer, des Sperrdatums und optional eines Sperrgrundes aus der in RFC 5280 definierten Liste , wie z. B. „Schlüsselkompromittierung“, „Zugehörigkeitsänderung“ oder „Betriebseinstellung“.

Das CRL-Format ist in RFC 5280 definiert. Dieser legt einen Standardsatz von Feldern fest, darunter den Distinguished Name des Ausstellers, den Zeitstempel „thisUpdate“, der angibt, wann die CRL veröffentlicht wurde, und den Zeitstempel „nextUpdate“, der angibt, wann die nächste CRL die aktuelle ersetzen wird. Die CRL wird mit dem privaten Schlüssel der ausstellenden Zertifizierungsstelle signiert. Dadurch kann jede vertrauende Partei ihre Authentizität überprüfen und Manipulationen erkennen, bevor sie sich auf ihren Inhalt verlässt.

Bei der Validierung des Zertifikatspfads ruft die vertrauende Partei die Sperrliste (CRL) von der in der CRL-Verteilungspunkt-Erweiterung des zu prüfenden Zertifikats angegebenen URL oder von einer anderen konfigurierten Quelle ab. Die vertrauende Partei prüft, ob die Seriennummer des Zertifikats in der CRL enthalten ist. Ist dies der Fall, gilt das Zertifikat als widerrufen und die Validierung schlägt unabhängig vom angegebenen Ablaufdatum fehl. Ist die Seriennummer nicht enthalten, besteht das Zertifikat die Widerrufsprüfung und die Validierung wird anhand anderer Kriterien fortgesetzt.

In Umgebungen mit hohem Datenaufkommen, in denen die CRL-Dateigrößen im Laufe der Zeit erheblich ansteigen, werden häufig Delta-CRLs verwendet, um den Bandbreiten- und Verarbeitungsaufwand für vollständige CRL-Downloads zu reduzieren. Eine Delta-CRL enthält lediglich die inkrementellen Änderungen seit der Veröffentlichung der letzten Basis-CRL. Vertrauende Parteien kombinieren die Basis-CRL mit der neuesten Delta-CRL, um das vollständige Sperrbild wiederherzustellen.

CRLs sind gut verstanden und in PKI-Umgebungen von Unternehmen weit verbreitet, obwohl operative Lücken in der Verfügbarkeit von Verteilungspunkten und im Gültigkeitszeitraummanagement weiterhin häufig auftreten. ARLs basieren auf derselben technischen Grundlage, behandeln aber ein grundlegend anderes Widerrufsproblem.

Liste der Genehmigungsentzüge

Eine Authority Revocation List (ARL) ist technisch gesehen eine Certificate Revocation List (CRL) und verwendet dieselbe ASN.1-kodierte Datenstruktur, denselben Signaturmechanismus, dasselbe Verteilungsmodell und dasselbe RFC-5280-Format, um den Widerrufsstatus von CA-Zertifikaten zu veröffentlichen. Der entscheidende Unterschied liegt im Umfang der aufgeführten Einträge. Während eine CRL widerrufene Endbenutzerzertifikate auflistet, listet eine ARL widerrufene CA-Zertifikate auf, insbesondere die Zertifikate, die von einer übergeordneten CA an die darunter stehenden Zwischen- oder Unterzertifizierungsstellen in der Hierarchie ausgestellt wurden.

Wenn eine Stammzertifizierungsstelle feststellt, dass das Zertifikat einer Zwischenzertifizierungsstelle widerrufen werden muss – sei es aufgrund eines Schlüsselkompromittierungsfalls, eines Betriebsfehlers, eines Richtlinienverstoßes oder der Außerbetriebnahme –, fügt sie die Seriennummer dieses Zertifikats ihrer ARL hinzu. Vertrauende Parteien, die eine vollständige Zertifikatspfadvalidierung durchführen, müssen die ARL für jede Zertifizierungsstelle in der Kette prüfen, nicht nur die CRL des Endbenutzerzertifikats. Wenn ein Zertifikat einer Zertifizierungsstelle in der Kette in einer gültigen ARL erscheint, schlägt die gesamte Pfadvalidierung fehl.

Die ARL unterscheidet sich von einer Standard-CRL durch die Erweiterung „Issuing Distribution Point“ im X.509 v2 CRL-Format. Diese Erweiterung enthält das Flag „onlyContainsCACerts“, das den vertrauenden Parteien signalisiert, dass die Liste Zertifizierungsstellenzertifikate und keine Endbenutzerzertifikate enthält. Die URL des Verteilungspunkts für die ARL ist im CA-Zertifikat selbst eingebettet und folgt dem gleichen Muster wie die Verteilungspunkte für CRL-Endbenutzerzertifikate.

Die betrieblichen Anforderungen an eine ARL unterliegen denselben Standards wie die einer CRL. NIST SP 800-57 Teil 1 legt fest, dass Widerrufsinformationen auf jeder Ebene der Zertifikatshierarchie aktuell und zugänglich sein müssen, da eine veraltete oder nicht verfügbare ARL dasselbe Risiko birgt wie eine fehlende CRL, mit dem Unterschied, dass sich das Risiko auf alle unter der betroffenen CA ausgestellten Zertifikate erstreckt und nicht nur auf eine einzelne Identität.

Sind beide Mechanismen vollständig definiert, so macht ein direkter Vergleich zwischen ihnen deutlich, welche operativen Kontrollen jeder einzelne erfordert und wo die Risiken einer Vernachlässigung des einen oder anderen Mechanismus am größten sind.

CRL gegen ARL

Obwohl CRL und ARL dieselbe technische Spezifikation aufweisen, unterscheiden sie sich hinsichtlich ihrer operativen Rollen, Aktualisierungsanforderungen und Fehlerfolgen in wesentlichen Punkten für die PKI-Governance. Die folgende Tabelle vergleicht beide Mechanismen anhand der für die Zertifikatsverwaltung in Unternehmen relevantesten Dimensionen.

Aspekt	CRL	ARL
Vollständiger Name	Sperrliste für Zertifikate	Liste der Genehmigungsentzüge
Was es auflistet	Widerrufene Endkundenzertifikate	Widerrufene CA-Zertifikate
Herausgegeben von	Die Zertifizierungsstelle, die die Endbenutzerzertifikate ausgestellt hat	Die übergeordnete Zertifizierungsstelle, die die Zwischenzertifizierungsstelle ausgestellt hat
Geprüft während	Validierung von Endbenutzerzertifikaten	Validierung des CA-Zertifikatpfads
Aktualisierungsfrequenz	Alle paar Stunden bis zu einmal täglich, je nach den Richtlinien Kaliforniens.	Alle paar Tage bis Wochen, da sich CA-Zertifikate selten ändern
Auswirkungen eines Fehlschusses	Einem Zertifikat wird weiterhin vertraut, obwohl es das nicht sollte.	Eine ganze CA-Kette genießt weiterhin Vertrauen, obwohl sie es nicht verdient.
Definiert in	RFC 5280 und X.509 v2	RFC 5280 und X.509 v2 (gleiches Format, unterschiedlicher Anwendungsbereich)
Übernahme durch Unternehmen	Weitgehend überwacht und verwaltet in den meisten Umgebungen	Häufig übersehen oder gar nicht umgesetzt

Die Auswirkungszeile ist der betrieblich bedeutendste Unterschied. Ein fehlender CRL-Eintrag ermöglicht es, dass ein einzelnes Zertifikat weiterhin als vertrauenswürdig gilt, obwohl es eigentlich hätte abgelehnt werden müssen. Ein fehlender ARL-Eintrag ermöglicht es einer gesamten Zwischenzertifizierungsstelle (Intermediate CA) sowie allen von ihr jemals ausgestellten Zertifikaten, weiterhin als vertrauenswürdig zu gelten, nachdem das eigene Zertifikat der Zertifizierungsstelle widerrufen wurde.

Die Aktualisierungshäufigkeit spiegelt eine ähnliche Asymmetrie wider. CRLs in aktiven Umgebungen werden oft alle paar Stunden aktualisiert, um der hohen Geschwindigkeit von Zertifikatsänderungen an Endbenutzer Rechnung zu tragen. ARLs werden seltener aktualisiert, da CA-Zertifikatsänderungen selten sind, ihre Gültigkeitsdauer erfordert jedoch dieselbe sorgfältige Konfiguration. Beide Mechanismen benötigen eine bewusste, richtlinienbasierte Konfiguration anstelle der bei der Erstbereitstellung übernommenen Standardeinstellungen.

In dieser operativen Realität stoßen Unternehmen am häufigsten auf Lücken im Widerrufsmanagement.

Häufige Unternehmenslücken

Sowohl im CRL- als auch im ARL-Management können im Laufe der Zeit operative Lücken entstehen, insbesondere wenn Widerrufsprozesse nicht regelmäßig überprüft werden. Die folgenden Lücken treten am häufigsten in Organisationen aller Größen auf.

• Für die Root-CA wurde keine ARL veröffentlicht. Viele interne PKI-Implementierungen verzichten gänzlich auf die Veröffentlichung einer ARL, da sie davon ausgehen, dass die Root-CA niemals eine Intermediate-CA widerrufen muss. Diese Annahme führt dazu, dass die Umgebung über keinen formalen Mechanismus zur Kommunikation eines Autoritätsentzugs auf Ebene der Zertifizierungsstelle verfügt, wenn es zu einer Kompromittierung oder Außerbetriebnahme kommt.
• ARL-Gültigkeitszeiten, die übermäßige Angriffsfenster schaffen. Eine ARL mit einer Gültigkeitsdauer von mehreren Monaten oder länger bedeutet, dass eine widerrufene Zwischenzertifizierungsstelle von jedem vertrauenden System, das die vorherige ARL zwischengespeichert hat, weiterhin als vertrauenswürdig eingestuft wird, bis diese zwischengespeicherte Kopie abläuft. Dadurch kann sich die Auswirkung einer Kompromittierung potenziell um Wochen oder Monate verlängern.
• Die Verfügbarkeit von CRL-Verteilungspunkten wird nicht aktiv überwacht. Wenn eine CRL- oder ARL-Verteilungspunkt-URL nicht mehr erreichbar ist, verhalten sich viele abhängige Systeme standardmäßig wie bei einem Fail-Open-Verfahren und behandeln das Zertifikat als gültig, anstatt die Validierung abzubrechen. Dies bedeutet, dass ein Infrastrukturausfall die Sperrprüfung in der gesamten Umgebung unbemerkt deaktivieren kann, ohne eine sofortige Warnung auszulösen.
• Widerrufsprozesse werden bei routinemäßigen PKI-Audits nicht geprüft. Die meisten PKI-Auditprozesse verifizieren die Ausstellung, Verlängerung und das Ablaufmanagement von Zertifikaten, aber nur wenige Organisationen testen regelmäßig den gesamten Widerrufsprozess. Tritt ein tatsächlicher Widerruf ein, ist der Prozess ungetestet und die einzelnen Schritte sind dem zuständigen Team unklar.
• Es existiert keine geführte Bestandsaufnahme der Zertifikatsabhängigkeiten der einzelnen Zwischenzertifizierungsstellen. Ohne einen aktuellen Überblick darüber, welche Systeme, Anwendungen und Dienste Zertifikate einer bestimmten Zwischenzertifizierungsstelle besitzen, lässt sich das Ausmaß der Folgen eines Widerrufs dieser Zertifizierungsstelle nicht abschätzen, und es ist unmöglich, vor der Verbreitung des ARL-Updates proaktiv mit betroffenen Teams zu kommunizieren.
• Speziell für das CRL-Management gelten dieselben Prinzipien auf Ebene der Endnutzer. Verfügbarkeit von Vertriebsstellen, Aktualität der CRLs und Zertifikatsbestand sind alles Bereiche, in denen Automatisierung und Zertifikatserkennung Die richtigen Werkzeuge machen einen messbaren Unterschied, und genau hier leisten speziell entwickelte Werkzeuge für das Zertifikatslebenszyklusmanagement ihren direkten Beitrag.

Entscheidungstabelle zur Überwachung des Widerrufs

Anhand dieser Tabelle können Sie Ihre aktuelle PKI-Konfiguration den erforderlichen Maßnahmen und den dafür zuständigen Personen zuordnen.

Situation	Software Empfehlungen	Eigentümer	Erwartetes Ergebnis
Für die Root-CA ist derzeit keine ARL veröffentlicht.	Veröffentlichen Sie eine ARL und konfigurieren Sie die Erweiterung „Ausstellender Verteilungspunkt“ mit dem Flag „onlyContainsCACerts“.	PKI-Team	Es existiert ein formaler Mechanismus zum Widerruf einer kompromittierten Zwischenzertifizierungsstelle.
Die Gültigkeitsdauer der ARL beträgt mehrere Monate oder länger.	Verkürzen Sie die Gültigkeitsdauer und stellen Sie sicher, dass die abhängigen Systeme ihre zwischengespeicherte Kopie gemäß diesem Zeitplan aktualisieren.	PKI-Team mit Sicherheitsteam-Überprüfung	Verringertes Belichtungsfenster bei Beeinträchtigung eines intermediären CA
Die Verfügbarkeit der CRL- oder ARL-Verteilerpunkte wird nicht aktiv überwacht.	Ergänzen Sie die bestehende Infrastrukturüberwachung um die Verfügbarkeit von Verteilungspunkten mit einer Fehlermeldung.	Plattform-/DevOps-Team	Ein Ausfall eines Verteilpunkts löst eine Warnung aus, anstatt die Widerrufsprüfung stillschweigend zu deaktivieren.
Der Widerrufsprozess wurde noch nie vollständig getestet.	Führen Sie einen Testlauf (provisorisch oder live) zur Aufhebung eines Nicht-Produktionszertifikats durch und bestätigen Sie, dass die abhängigen Systeme es ablehnen.	Sicherheitsteam	Das Vertrauen, dass der Widerrufsweg funktioniert, bevor ein tatsächlicher Vorfall eintritt, erfordert dies.
Es liegt keine Übersicht darüber vor, welche Systeme Zertifikate unter den jeweiligen Zwischenzertifizierungsstellen halten.	Erstellen und pflegen Sie ein Zertifikatsverzeichnis, das den ausstellenden Zertifizierungsstellen zugeordnet ist.	PKI-Team arbeitet mit dem Compliance-Team zusammen, um Prüfungsnachweise zu erhalten.	Die potenziellen Auswirkungen eines zukünftigen Entzugs der CA-Lizenz können im Voraus abgeschätzt werden.

Verantwortlichkeits-/Aktionsmatrix nach Team

Team	Hauptverantwortung	Schlüsselaktion
PKI-Team	CRL- und ARL-Veröffentlichung, Gültigkeitszeiträume, CA-Hierarchie-Design	Bestätigen Sie, dass für jede Root- und Zwischenzertifizierungsstelle eine ARL existiert und dass die Gültigkeitszeiträume bewusst festgelegt und nicht voreingestellt sind.
Sicherheitsteam	Prüfung des Widerrufs-Workflows, Reaktion auf Vorfälle	Testen Sie den Widerrufspfad vollständig und bestätigen Sie, dass abhängige Systeme bei einem Ausfall des Verteilungspunkts geschlossen und nicht offen ausfallen.
Plattform-/DevOps-Team	Infrastruktur und Überwachung der Verteilerpunkte	Ergänzen Sie die bestehende Uptime-Überwachung um die Verfügbarkeit von CRL/ARL-Verteilerpunkten mit einer Benachrichtigungsfunktion.
Compliance-Team	Prüfungsnachweise für Widerrufskontrollen	Bestätigen Sie, dass Widerrufstests und die Zertifikatsinventur als Teil der PKI-Auditnachweise dokumentiert werden.

Was macht man als nächstes

Für PKI-Teams

Stellen Sie sicher, dass jede Root- und Zwischenzertifizierungsstelle in Ihrer Hierarchie über eine veröffentlichte ARL mit einer bewusst konfigurierten Gültigkeitsdauer verfügt und nicht über einen Standardwert aus der ursprünglichen Bereitstellung.

Für Sicherheitsteams

Führen Sie einen Live- oder Tabletop-Test des Widerrufsworkflows durch und überprüfen Sie dabei, wie sich abhängige Systeme verhalten, wenn ein Verteilungspunkt nicht erreichbar ist.

Für Plattform-/DevOps-Teams

Fügen Sie CRL- und ARL-Verteilungspunkt-Endpunkte zur bestehenden Uptime-Überwachung hinzu, damit ein Ausfall eine Warnung auslöst, anstatt die Widerrufsprüfung stillschweigend zu deaktivieren.

Für Compliance-Teams

Bestätigen Sie, dass die Tests des Widerrufsworkflows und die Inventarisierung der Zertifikatsabhängigkeiten als Prüfnachweise erfasst werden, nicht nur die Ausstellungs- und Verlängerungsdatensätze.

Wie Verschlüsselungsberatung helfen kann

Der CertSecure Manager von Encryption Consulting bietet eine PKI- Integritätsübersicht zur frühzeitigen Erkennung und Überwachung solcher Ausfälle. Im Folgenden wird detailliert erläutert, wie der CertSecure Manager bei der Behebung dieser Probleme hilft:

CertSecure führt eine detaillierte Prüfung aller Komponenten der Zertifizierungsstelle durch und zeigt alle CDP- und AIA-Informationen sowie die verbleibenden Tage der CRL an. Wird ein Fehler festgestellt, benachrichtigt die Lösung die Administratoren automatisch.

• Detaillierte Prüfung: CertSecure überprüft alle Komponenten der Zertifizierungsstelle und bietet eine zentrale Übersicht über den Zustand der PKI.
• CDP-, AIA-Punkte: Es identifiziert die CDP- und Authority Information Access (AIA)-Punkte zur Lokalisierung der CRL.
• Restgültigkeitsdauer der Sperrliste: Hier wird die verbleibende Gültigkeitsdauer der Sperrliste angezeigt. Dies hilft Administratoren, die Liste zu aktualisieren und das Risiko zu minimieren, sich auf veraltete Sperrlisten zu verlassen.
• Automatisierte Warnmeldungen: CertSecure bietet einen integrierten Warnmechanismus, um die Administratoren über den Ablauf der Gültigkeit zu informieren, sowie ein Incident-Management für den Fall von Fehlern im Zusammenhang mit CRLs.

Die Plattform ist speziell für die CRL-gesteuerten Widerrufsprozesse entwickelt, die die Grundlage für das Vertrauen in Unternehmenszertifikate bilden. Dadurch wird die Zertifikatsautomatisierung für den Widerruf proaktiv, auditierbar und skalierbar – auch bei wachsender Zertifikatsumgebung. Dieselbe Erkennungsschicht, die den Status von CRLs und ARLs überwacht, fließt auch in die umfassenderen CBOM Secure- und PQC- Vorbereitungsmaßnahmen ein. Unser PQC Center of Excellence erläutert, wie Zertifikatserkennung, Krypto-Agilität und Widerrufsinfrastruktur im Rahmen der Post-Quantum-Migration von Unternehmen miteinander verknüpft sind. Erfahren Sie mehr darüber , wie ein CBOM Bestandsdaten in kontinuierliche Informationen für diese Verbindung umwandelt .

Fazit

CRLs und ARLs erfüllen dieselbe grundlegende Anforderung aus unterschiedlichen Positionen innerhalb der PKI-Vertrauenshierarchie. Eine CRL kommuniziert den Widerruf einzelner Endbenutzerzertifikate, während eine ARL den Widerruf von CA-Zertifikaten und damit die gesamte darunterliegende Zertifikatshierarchie ungültig macht. Beide sind in RFC 5280 definiert, unterscheiden sich jedoch hinsichtlich ihrer Bedeutung, Aktualisierungsanforderungen und Fehlerfolgen erheblich.

In der Praxis ist das CRL-Management in Unternehmensumgebungen gut etabliert, obwohl die Überwachung von Verteilungspunkten und das Testen von Widerrufs-Workflows weiterhin Bereiche mit bestehenden Lücken darstellen. Das ARL-Management folgt denselben Prinzipien und wird entsprechend der CA-Hierarchie der jeweiligen Organisation angewendet.

CertSecure Manager bietet Unternehmen die operative Infrastruktur zur Verwaltung von CRL-Workflows mit der Transparenz, Automatisierung und Nachvollziehbarkeit, die in PKI-Umgebungen für Unternehmen erforderlich sind. Für Teams, die ihre Zertifikatssperrstrategie verbessern möchten, ist Encryption Consulting ein praktischer Ausgangspunkt.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus CRL vs ARL: Warum beide in der PKI wichtig sind?

Eine CRL und eine ARL verwenden zwar das gleiche RFC-5280-Format, operieren aber auf unterschiedlichen Ebenen der PKI-Vertrauenshierarchie. Eine CRL widerruft Endbenutzerzertifikate einzeln, während eine ARL CA-Zertifikate und damit alle Zertifikate widerruft, die die betroffene CA jemals ausgestellt hat. Viele PKI-Implementierungen in Unternehmen verwalten CRLs zwar korrekt, veröffentlichen aber nie eine ARL. Dadurch fehlt ein formaler Mechanismus zum Widerruf einer kompromittierten Zwischenzertifizierungsstelle.

Warum ist das für das Zertifikatslebenszyklusmanagement in Unternehmen von Bedeutung?

Ein fehlender CRL-Eintrag führt dazu, dass ein Zertifikat fälschlicherweise als vertrauenswürdig eingestuft wird. Ein fehlender ARL-Eintrag kann eine gesamte Zertifizierungsstelle kompromittieren und alle von ihr ausgestellten Zertifikate irrtümlich als vertrauenswürdig einstufen – mit weitaus größeren Folgen. Die DigiCert Trust Pulse Survey vom Juli 2025 ergab, dass 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten aufgrund von Zertifikatsproblemen verzeichneten, wobei 37.5 % davon auf abgelaufene oder nicht ordnungsgemäß validierte Zertifikate zurückzuführen waren. Dies unterstreicht, wie stark sich eine sorgfältige Verwaltung von Zertifikatssperrungen auf das Gesamtrisiko im Zertifikatslebenszyklus auswirkt.

Welche Teams sind für die Umsetzung dieser Vorgaben verantwortlich?

Die PKI-Teams sind für die Konfiguration der Veröffentlichung und Gültigkeitsdauer von CRLs und ARLs verantwortlich. Die Sicherheitsteams testen den gesamten Widerrufsprozess und bestätigen das korrekte Verhalten bei Fehlern. Die Plattform- und DevOps-Teams überwachen die Verfügbarkeit der Verteilungspunkte. Die Compliance-Teams dokumentieren Widerrufstests und Zertifikatsinventare als Prüfnachweise.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Die manuelle, unüberwachte Verwaltung von Widerrufszertifikaten birgt das Risiko, dass ein Verteilungspunkt unbemerkt unerreichbar wird, da viele abhängige Systeme im Fehlerfall offen statt geschlossen bleiben. Zudem besteht die Gefahr, dass erst im Zuge eines tatsächlichen Sicherheitsvorfalls festgestellt wird, dass für die Stammzertifizierungsstelle nie ein ARL veröffentlicht wurde.

Wie kann Automatisierung das Risiko von Zertifikatsausfällen verringern?

Die automatisierte Überwachung von CRL- und ARL-Verteilungspunkten, der verbleibenden Gültigkeitsdauer und Zertifikatsabhängigkeiten macht die manuelle Überprüfung dieser Details überflüssig. Plattformen wie CertSecure Manager zeigen CDP- und AIA-Punkte an, kennzeichnen bevorstehende CRL-Abläufe und benachrichtigen Administratoren automatisch. Dadurch wird die Lücke geschlossen, die zu unbemerkten Widerrufsfehlern führt.

Welche Kennzahlen sollten die Teams nach der Implementierung verfolgen?

Verfolgen Sie die Verfügbarkeit der ARL- und CRL-Verteilungspunkte, die verbleibende Gültigkeitsdauer jeder Liste, die Zeit seit dem letzten vollständigen Test des Widerrufs-Workflows und ob jede Root- und Zwischenzertifizierungsstelle in der Hierarchie über eine veröffentlichte, aktuelle ARL verfügt.

Wie hängt das mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammen?

Der Wahlvorschlag SC-081v3 des CA/Browser Forums sieht eine schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate vor: auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage im März 2029. Eine höhere Ausstellungs- und Erneuerungsfrequenz bedeutet auch mehr Datenverkehr zur Überprüfung der Gültigkeit von Zertifikaten anhand von Sperrlisten (CRLs), wodurch die Zuverlässigkeit der Verteilungspunkte und die Aktualität der CRLs mit sinkenden Gültigkeitsdauern zu wichtigeren Betriebsfaktoren werden.

Wie sollte dies in Multi-Cloud- oder Hybrid-PKI-Umgebungen gehandhabt werden?

Multi-Cloud- und Hybridumgebungen betreiben häufig separate CA-Hierarchien pro Cloud sowie eine interne ADCS-Bereitstellung, jeweils mit eigenen CRL- und ARL-Verteilungspunkten. Die zentrale Erkennung und Überwachung aller Hierarchien, anstatt jede einzeln zu prüfen, ermöglicht es, veraltete ARLs oder nicht erreichbare Verteilungspunkte zu erkennen, bevor es zu einem Ausfall kommt.

Welche Option ist die beste für große Unternehmen?

CRL und ARL sind keine Alternativen, zwischen denen man wählen kann; beide sind für ein vollständiges Widerrufsmodell erforderlich. Große Unternehmen mit mehrstufigen CA-Hierarchien und hohem Zertifikatsvolumen haben am meisten unter einer fehlenden oder veralteten ARL zu leiden, da die Auswirkungen einer Kompromittierung einer nicht widerrufenen Zwischenzertifizierungsstelle mit der Anzahl der von ihr abhängigen Zertifikate und Systeme skalieren. Daher gewinnt die automatisierte ARL-Überwachung mit zunehmender Hierarchie immer mehr an Bedeutung.

Welche Kriterien sollten Teams zur Bewertung von CRL- und ARL-Tools heranziehen?

Bewerten Sie die Tools danach, ob sie sowohl CRL als auch ARL überwachen, nicht nur CRL; ob sie CDP- und AIA-Punkte sowie die verbleibende Gültigkeitsdauer automatisch anzeigen; ob sie bei Ausfällen von Verteilungspunkten Alarm schlagen, anstatt stillschweigend auszufallen; und ob sie ein Zertifikatsabhängigkeitsverzeichnis führen, mit dem Sie den Wirkungsradius beurteilen können, bevor Sie eine Zertifizierungsstelle widerrufen.