Was ist eine Zertifikatssperrliste (CRL)?

Warum die Sperrung von Zertifikaten wichtig ist

Digitale Zertifikate dienen dazu, Vertrauen bei Online-Transaktionen zu schaffen. Erst wenn Vertrauen aufgebaut und die Identität des Gegenübers bestätigt wurde, ist es möglich, einen authentifizierten und verschlüsselten Kommunikationskanal herzustellen. Zusammen bilden diese Eigenschaften die Grundlage der Public-Key-Infrastruktur (PKI), auf der praktisch jede sichere digitale Interaktion basiert.

Jedes Zertifikat wird mit einer begrenzten Gültigkeitsdauer ausgestellt, die je nach den Richtlinien der ausstellenden Zertifizierungsstelle (CA) von Stunden bis zu mehreren Jahren reichen kann. Es ist jedoch erwähnenswert, dass die maximale Gültigkeitsdauer für ein öffentlich vertrauenswürdiges digitales Zertifikat ab März 2029 nur noch 47 Tage betragen wird. Ein Zertifikat verliert sofort seine Gültigkeit, sobald bekannt wird, dass sein privater Schlüssel kompromittiert wurde – unabhängig davon, wie viel Zeit bis zum Ablauf der Gültigkeitsdauer noch verbleibt. Die Gültigkeitsdauer verliert ihre Bedeutung, sobald die Vertrauensgrundlage nicht mehr gegeben ist.

Ein privater Schlüssel kann durch eine Sicherheitslücke oder eine Fehlkonfiguration kompromittiert werden. Ein Mitarbeiter mit einem Client-Zertifikat kann das Unternehmen verlassen. Eine Zertifizierungsstelle (CA) muss unter Umständen selbst das Vertrauen in von ihr ausgestellte Zertifikate widerrufen. Ohne einen zuverlässigen Mechanismus zur Ungültigmachung von Zertifikaten vor ihrem regulären Ablaufdatum sind Unternehmen Angriffen ausgesetzt, bei denen Anmeldedaten ausgenutzt werden, die von der PKI nicht mehr als vertrauenswürdig eingestuft werden.

Die Zertifikatssperrung ist dieser Mechanismus, und die Zertifikatssperrliste (CRL) ist ihre älteste und am weitesten verbreitete Umsetzung.

Was ist eine Zertifikatssperrung?

Unter Zertifikatswiderruf versteht man die Ungültigmachung eines digitalen Zertifikats vor dessen geplantem Ablaufdatum. Dies ist ein grundlegender Vorgang innerhalb der PKI, der sicherstellt, dass Zertifikate, die nicht mehr als vertrauenswürdig gelten, nicht mehr zur Authentifizierung von Identitäten oder zur Verschlüsselung der Kommunikation verwendet werden können.

Während der Gültigkeitsdauer eines Zertifikats kann der Zertifikatsinhaber oder die Zertifizierungsstelle (CA), die das Zertifikat ausgestellt hat, feststellen, dass diesem nicht mehr vertraut werden sollte. In diesem Fall muss das nicht mehr vertrauenswürdige Zertifikat widerrufen und die vertrauenden Parteien (Browser, Server, Anwendungen usw.) müssen darüber informiert werden. Der wichtigste Mechanismus zur Bekanntgabe dieses Widerrufsstatus ist die Zertifikatswiderrufsliste.

In einer gut verwalteten PKI ist die Möglichkeit, das Vertrauen zu widerrufen, von grundlegender Bedeutung. Diese Kontrollmaßnahme gewährleistet die Integrität der Vertrauenskette, wenn sich die realen Bedingungen schneller ändern, als es die Gültigkeitsdauer der Zertifikate zulässt.

Was ist eine Zertifikatssperrliste?

Eine Zertifikatssperrliste kann auf verschiedenen Detailebenen definiert werden:

Im Grunde genommen ist eine CRL eine Liste der Seriennummern widerrufener Zertifikate, die von einer Zertifizierungsstelle veröffentlicht wird.

Der CA-Sicherheitsrat definiert dies als „eine digital signierte Datei, die eine Liste von Zertifikaten enthält, die widerrufen wurden und deren Gültigkeit noch nicht abgelaufen ist“.

RFC 5280, der Internetstandard, der die X.509-PKI regelt, liefert die formale Definition: Eine CRL ist „eine mit einem Zeitstempel versehene und signierte Datenstruktur, die eine Zertifizierungsstelle (CA) oder ein CRL-Aussteller in regelmäßigen Abständen herausgibt, um den Widerrufsstatus betroffener digitaler Zertifikate mitzuteilen.“

Das CRL-Format ist im X.509-Standard definiert und in RFC 5280 detailliert beschrieben. Jeder Eintrag in einer CRL enthält die Seriennummer des widerrufenen Zertifikats und das Datum des Widerrufs. Optional können Einträge eine zeitliche Begrenzung des Widerrufs sowie einen Grundcode enthalten, der erklärt, warum das Zertifikat widerrufen wurde.

Zertifizierungsstellen veröffentlichen CRLs in regelmäßigen Abständen (stündlich, täglich oder wöchentlich, je nach Richtlinie und Risikotoleranz). Ein widerrufenes Zertifikat kann in einer CRL einen von zwei Status haben:

• Widerrufen: Der Widerruf ist dauerhaft und unwiderruflich. Dem Zertifikat wird nie wieder vertraut.
• „Hold“: Der Widerruf ist vorübergehend. Die Vertrauenswürdigkeit des Zertifikats wird ausgesetzt, kann jedoch bei einer Änderung der Umstände wiederhergestellt werden.

So funktionieren Zertifikatssperrlisten

Die Rolle der Zertifizierungsstelle

CRLs werden von der Zertifizierungsstelle ausgestellt und gepflegt, die die Zertifikate ursprünglich ausgestellt hat. Die Zertifizierungsstelle versieht jede von ihr veröffentlichte CRL mit einer digitalen Signatur, und diese Signatur ist von entscheidender Bedeutung: Sie belegt die Echtheit der Datei und verhindert Manipulationen.

Jede vertrauende Partei, die eine CRL herunterlädt, kann die Signatur der Zertifizierungsstelle überprüfen, um sicherzustellen, dass die Liste während der Übertragung nicht verändert wurde. In den meisten Fällen wird die CRL von derselben Stelle signiert, die auch die Zertifikate ausgestellt hat. In manchen Fällen benennt eine Zertifizierungsstelle jedoch einen anderen autorisierten Unterzeichner, der CRLs in ihrem Namen ausstellt – eine Konfiguration, die zwar vom X.509-Standard unterstützt wird, in der Praxis jedoch selten zum Einsatz kommt.

Aufbau und Inhalt des CRL

Gemäß RFC 5280 enthält eine CRL die folgenden Schlüsselfelder:

• Name des Ausstellers: Der Distinguished Name der Zertifizierungsstelle, die die CRL ausgestellt hat
• In dieser Aktualisierung: Datum und Uhrzeit der Veröffentlichung der CRL
• Nächstes Update: Datum und Uhrzeit, zu denen die nächste CRL veröffentlicht wird (d. h. das Ablaufdatum der CRL)
• Liste der widerrufenen Zertifikate: Eine Folge von Einträgen, die jeweils Folgendes enthalten:
  • Die Seriennummer des widerrufenen Zertifikats
  • Das Datum des Widerrufs
  • Optionale Erweiterungen, einschließlich Codes für Widerrufsgründe
• Digitale Signatur der Zertifizierungsstelle: Authentifiziert die gesamte CRL

Gemäß RFC 5280 werden abgelaufene Zertifikate in der Regel aus der CRL entfernt, sobald ihre ursprüngliche Gültigkeitsdauer abgelaufen ist, da sie unabhängig von ihrem Sperrstatus nicht mehr akzeptiert würden. Dieses Verhalten kann jedoch von der Zertifizierungsstelle konfiguriert werden.

CRL-Einträge und Gründe für den Widerruf

Der X.509-Standard definiert mehrere Begründungscodes, die eine Zertifizierungsstelle (CA) einem CRL-Eintrag hinzufügen kann. Diese Codes liefern Informationen darüber, warum ein Zertifikat widerrufen wurde, was für forensische Analysen und für die Entscheidung wichtig sein kann, ob vor dem Widerrufsdatum signierte Inhalte weiterhin als vertrauenswürdig gelten sollten.

Zu den Standard-Grundcodes gehören:

• Kompromittierung des Schlüssels: Der private Schlüssel des Zertifikats wurde kompromittiert. Inhalte, die zuvor mit diesem Schlüssel signiert wurden, sollten nicht als vertrauenswürdig angesehen werden.
• Kompromittierung der Zertifizierungsstelle: Der private Schlüssel der ausstellenden Zertifizierungsstelle wurde kompromittiert, wodurch alle von ihr ausgestellten Zertifikate in Frage gestellt werden.
• Zugehörigkeit geändert: Die organisatorische Zugehörigkeit des Zertifikatsinhabers hat sich geändert (beispielsweise wurde eine Tochtergesellschaft verkauft).
• Ersetzt: Das Zertifikat wurde durch ein neueres Zertifikat ersetzt.
• Einstellung des Betriebs: Das Unternehmen hat seinen Betrieb eingestellt, oder die mit dem Zertifikat verknüpfte Domain bzw. der Server befindet sich nicht mehr im Besitz des Zertifikatsinhabers.
• Entzug der Berechtigung: Die Berechtigung des Zertifikatsinhabers hat sich geändert (beispielsweise hat ein Mitarbeiter das Unternehmen verlassen). Vor dem Entzug erteilte Signaturen können weiterhin als gültig angesehen werden, da der Inhaber zum Zeitpunkt der Signatur berechtigt war.
• Zertifikatssperre: Das Zertifikat ist vorübergehend gesperrt. Es kann durch einen „removeFromCRL“-Eintrag in einer nachfolgenden Delta-CRL wieder freigeschaltet werden.

Zertifikate können auch widerrufen werden, wenn sie unsachgemäß ausgestellt, durch Betrug erlangt oder unter Verstoß gegen die Zertifikatsrichtlinien der Zertifizierungsstelle ausgestellt wurden.

Wie Browser und Anwendungen CRLs überprüfen

Wenn ein Benutzer eine Verbindung zu einer Website oder einem Dienst herstellt, die bzw. der durch ein digitales Zertifikat gesichert ist, führt die vertrauende Partei (Browser, Anwendung oder Betriebssystem) eine Reihe von Validierungsschritten durch. Die CRL-Prüfung ist ein zentraler Bestandteil dieses Prozesses:

1. CRL-Verteilungspunkte: Zum Zeitpunkt ihrer Erstellung enthalten Zertifikate eine CRL-Verteilungspunkte-Erweiterung (CDP), in der eine oder mehrere URLs aufgeführt sind, unter denen die CRL der ausstellenden Zertifizierungsstelle abgerufen werden kann, wenn eine Validierung erforderlich ist.
2. TLS : Beim Aufbau einer TLS initiiert der Browser die Verbindung und empfängt das Zertifikat des Servers.
3. Abruf und Überprüfung der CRL: Der Browser ruft die CRL von der in der CDP-Erweiterung des Zertifikats angegebenen URL ab und überprüft, ob die Seriennummer des Zertifikats in der Liste enthalten ist.
4. Entscheidung: Befindet sich das Zertifikat nicht in der CRL, wird die Verbindung hergestellt. Ist es dort aufgeführt, warnt der Browser den Benutzer, dass das Zertifikat widerrufen wurde und der Verbindung nicht vertraut werden sollte.

Diese Validierung ist ein wesentlicher Schritt bei jeder PKI-basierten Transaktion. Sie wirft jedoch ein praktisches Problem auf: Verfügt der Browser nicht über eine aktuelle, lokal zwischengespeicherte Kopie der CRL, muss er die vollständige CRL bei der ersten Verbindung abrufen, was zu einer zusätzlichen Latenz führt. Um dies zu vermeiden, speichern Browser CRLs zwar im Cache, doch dadurch entsteht ein Zeitfenster, in dem ein kürzlich widerrufenes Zertifikat weiterhin akzeptiert wird.

Arten von Zertifikatssperrlisten

Vollständige (kombinierte) CRLs

Eine vollständige CRL, die manchmal auch als „kombinierte CRL“ bezeichnet wird, enthält alle widerrufenen Zertifikate der ausstellenden Zertifizierungsstelle, die noch nicht abgelaufen sind. Jedes Mal, wenn die Zertifizierungsstelle eine aktualisierte CRL veröffentlicht, erstellt sie die vollständige Liste von Grund auf neu.

Vollständige CRLs lassen sich unkompliziert implementieren und werden von allen PKI-Clients umfassend unterstützt. Das Format lässt sich leicht überprüfen. Jede vertrauende Partei, die die CRL herunterlädt, erhält einen vollständigen Überblick über den Sperrstatus. Für Zertifizierungsstellen, die eine große Anzahl von Zertifikaten gesperrt haben, können vollständige CRLs jedoch extrem groß werden, was erhebliche Bandbreite beansprucht und die Downloadzeiten verlängert. Daher eignen sie sich am besten für kleinere PKI-Implementierungen, bei denen die Gesamtzahl der gesperrten Zertifikate überschaubar bleibt.

Partitionierte CRLs

Bei partitionierten CRLs werden die Sperrinformationen auf mehrere separate CRL-Dateien verteilt. Diese Option ermöglicht es, die Seriennummern der gesperrten Zertifikate auf eine vorab festgelegte Anzahl von Partitionen zu verteilen. Den Zertifikaten wird bei ihrer Ausstellung eine zufällig generierte CRL-Partitionsnummer zugewiesen. Auf diese Weise können vertrauende Parteien über die CDP-Erweiterung die richtige Partition identifizieren und die entsprechende Partition anfordern.

Der Vorteil liegt in der Skalierbarkeit. Anstatt eine einzige umfangreiche CRL herunterzuladen, lädt eine vertrauende Partei nur die Partition herunter, die für das zu validierende Zertifikat relevant ist. Dieser Ansatz reduziert den Bandbreitenverbrauch, beschleunigt die CRL-Generierung auf Seiten der Zertifizierungsstelle und ermöglicht die unabhängige Zwischenspeicherung jeder einzelnen Partition. Allerdings setzt dies voraus, dass sowohl die vertrauende Partei als auch die partitionierten CRLs den Standardansatz für PKIs großer Unternehmen darstellen, die Zehntausende von Zertifikaten oder mehr verwalten.

Delta-CRLs

Eine Delta-CRL enthält lediglich die Änderungen (Hinzufügungen und Löschungen) seit der Veröffentlichung der letzten vollständigen (Basis-)CRL. Anstatt die gesamte Liste erneut herunterzuladen, muss eine vertrauende Partei, die bereits über die Basis-CRL verfügt, lediglich die Delta-CRL abrufen, um ihre Sperrdaten auf den aktuellen Stand zu bringen.

Delta-CRLs reduzieren den Bandbreitenbedarf erheblich, insbesondere in Umgebungen mit umfangreichen Basis-CRLs und relativ wenigen Sperrungen zwischen den Veröffentlichungszyklen. Sie sind jedoch in hohem Maße von der Basis-CRL abhängig, sodass die Überprüfung auch dann fehlschlagen kann, wenn die Delta-CRL verfügbar ist.

CRL-Lebenszyklus: Aktualisierungen, Ablauf und Häufigkeit

Aktualisierungshäufigkeit und das Feld „Nächstes Update“

Jede CRL enthält einen Zeitstempel für das „nächste Update“, der den vertrauenden Parteien mitteilt, wann mit der nächsten Version zu rechnen ist. Zertifizierungsstellen veröffentlichen neue CRLs nach einem Zeitplan, der in ihrer Zertifizierungsrichtlinie festgelegt ist:

• CRLs der Stamm-Zertifizierungsstelle: Werden in Abständen von einigen Monaten bis zu mehreren Jahren veröffentlicht. Die privaten Schlüssel der Stamm-Zertifizierungsstelle werden offline gespeichert, sodass für die Erstellung der CRLs physischer Zugriff auf den Signaturschlüssel erforderlich ist.
• Ausgabe von (untergeordneten) CA-CRLs: Veröffentlichung im Abstand von einigen Stunden bis zu mehreren Tagen. Diese Zertifizierungsstellen sind online und können die Erstellung von CRLs leichter automatisieren.

Die Häufigkeit hängt stark von den Richtlinien der Zertifizierungsstelle ab. Eine Offline-Root-CA (eine Zertifizierungsstelle, die aus Sicherheitsgründen offline betrieben wird) erstellt möglicherweise jedes Jahr eine neue CRL oder sogar noch seltener. Im Gegensatz dazu erstellt eine ausstellende Zertifizierungsstelle in einer Hochsicherheitsumgebung möglicherweise stündlich eine neue CRL oder sogar noch häufiger.

Administratoren können zudem unmittelbar nach einem Sperrereignis mit hoher Priorität die manuelle Veröffentlichung der CRL auslösen, um sicherzustellen, dass die Sperrung weitergegeben wird, ohne auf die nächste geplante Aktualisierung warten zu müssen.

Was passiert, wenn eine CRL abläuft?

Wenn eine CRL den Zeitpunkt der „nächsten Aktualisierung“ erreicht und noch keine Ersatz-CRL veröffentlicht wurde oder wenn der CRL-Endpunkt nicht mehr erreichbar ist, hat dies schwerwiegende Folgen: Alle von dieser Zertifizierungsstelle ausgestellten Zertifikate werden sofort unbrauchbar. Vertrauensparteien, die keine gültige, aktuelle CRL abrufen können, haben keine Möglichkeit zu überprüfen, ob ein Zertifikat widerrufen wurde, und viele werden das Zertifikat daher sofort ablehnen.

Dieses Verhalten (Fail-Closed) ist die sichere Standardeinstellung. Einige Implementierungen bieten eine Fail-Open-Option an, bei der Zertifikate auch dann akzeptiert werden, wenn keine aktuelle CRL abgerufen werden kann. Dabei wird jedoch Sicherheit zugunsten der Verfügbarkeit geopfert, weshalb diese Option für Produktionsumgebungen nicht empfohlen wird.

Das Ablaufen von CRLs ist eine der häufigsten Ursachen für unerwartete PKI-Ausfälle, weshalb die Überwachung von CRLs eine entscheidende betriebliche Anforderung darstellt.

So überprüfen Sie eine Zertifikatssperrliste

Zertifikate enthalten eine CRL-Verteilungspunkte-Erweiterung (CDP), die die URLs enthält, unter denen die entsprechende CRL heruntergeladen werden kann. Es gibt mehrere gängige Methoden zur Überprüfung einer CRL:

• Windows: Mit dem command „certutil“ lassen sich CRL-Inhalte herunterladen, analysieren und anzeigen.
• macOS und Linux: OpenSSL bietet Befehle zum Abrufen und Dekodieren von CRLs aus CDP-URLs.
• Browser: Moderne Browser führen während TLS automatisch eine CRL- (oder OCSP-)Validierung durch und warnen die Nutzer, wenn ein Zertifikat widerrufen wurde.

Im Keyfactor Center steht eine spezielle Anleitung zur Überprüfung von CRLs mit bestimmten Tools und Befehlen zur Verfügung.

Warum CRLs wichtig sind

Ohne eine funktionierende Zertifikatssperrung verliert die PKI ihre Fähigkeit, auf sich ändernde Vertrauensbedingungen zu reagieren. Die Risiken eines Betriebs ohne effektives CRL-Management sind erheblich:

• Vertrauensüberprüfung: CRLs sind der Mechanismus, der bestätigt, dass ein Zertifikat von der ausstellenden Zertifizierungsstelle weiterhin als vertrauenswürdig eingestuft wird. Ohne sie haben vertrauende Parteien keine Möglichkeit, ein gültiges Zertifikat von einem kompromittierten Zertifikat zu unterscheiden.
• Rückwirkende Sperrung: CRL-Einträge enthalten das Sperrdatum, sodass Organisationen feststellen können, wann das Vertrauen entzogen wurde. Dies ist für forensische Untersuchungen von entscheidender Bedeutung, da die Kenntnis des genauen Zeitpunkts, zu dem ein Zertifikat als nicht mehr vertrauenswürdig eingestuft wurde, Auswirkungen auf die Gültigkeit aller damit signierten Dokumente hat.
• Datenschutzverletzungen: Ein kompromittiertes Zertifikat, das weiterhin als vertrauenswürdig eingestuft wird, ermöglicht Man-in-the-Middle-Angriffe (MITM). Angreifer können verschlüsselten Datenverkehr abfangen, der Sozialversicherungsnummern, Bankkontodaten, Kreditkartendaten und geschützte Gesundheitsdaten enthält.
• Identitätsdiebstahl und Identitätsmissbrauch: Nicht widerrufene, kompromittierte Zertifikate können für den Diebstahl von Zugangsdaten und für „Business Email Compromise“-Kampagnen (BEC) genutzt werden, wodurch Angreifer sich als vertrauenswürdige Stellen ausgeben können.
• Finanzieller Schaden: Gestohlene Bankzugangsdaten, Zahlungskartendaten und Authentifizierungstoken von Unternehmen können über Verbindungen abgegriffen werden, die auf Zertifikaten basieren, die eigentlich hätten widerrufen werden müssen.
• Verbreitung von Malware: Manipulierte Code-Signing- oder TLS können dazu genutzt werden, Keylogger zu installieren, Ransomware zu verbreiten oder Geräte in DDoS-Botnetze einzubinden – und das alles, ohne dass dies auf den Systemen der Opfer auffällt.

Demo anfordern

CRL-Verteilung und -Hosting

CRL-Verteilstellen (CDPs)

Ein CRL-Verteilungspunkt (CRL Distribution Point, CDP) ist der Ort (in der Regel eine URL auf einem LDAP-Verzeichnisserver oder Webserver), an dem eine Zertifizierungsstelle (CA) ihre CRLs veröffentlicht. Die CDP-URL wird über die CDP-Erweiterung in jedes von der CA ausgestellte Zertifikat eingebettet, damit vertrauende Parteien wissen, wo sie die CRL abrufen können.

CDPs müssen jederzeit erreichbar sein. Wenn eine vertrauende Partei den CDP nicht kontaktieren kann, um eine aktuelle CRL abzurufen, schlägt die Zertifikatsvalidierung fehl. Aus diesem Grund werden LDAP-basierte CDPs für öffentlich zugängliche PKI-Systeme nicht empfohlen. Webserver-basierte (HTTP/HTTPS) CDPs sind der Standard für die meisten Implementierungen.

Hosting-Strategien

Unternehmen stehen verschiedene Optionen für das Hosting von CRL-Endpunkten zur Verfügung, die sich jeweils hinsichtlich ihrer Verfügbarkeit und Skalierbarkeit unterscheiden:

• Webserver: Der einfachste Ansatz. Ein Standard-HTTP-Server hostet die CRL-Dateien, und die Zertifikate verweisen auf dessen URL als CDP. Geeignet für kleine bis mittelgroße PKIs.
• Content Delivery Networks (CDNs): Verteilen Sie CRL-Dateien auf geografisch verteilte Edge-Knoten und sorgen Sie so für hohe Verfügbarkeit und geringe Latenz bei globalen Bereitstellungen.
• Webfarmen: Mehrere Webserver hinter einem Load Balancer sorgen für Redundanz und Ausfalltoleranz.
• LDAP-Verzeichnisse: Wurden früher in Active-Directory-Umgebungen von Unternehmen verwendet. Für neue Bereitstellungen weitgehend veraltet, da mittlerweile die HTTP-basierte Verteilung bevorzugt wird.

Überlegungen zum Caching

Vertrauende Parteien speichern CRLs lokal im Cache, bis der Zeitstempel für das „nächste Update“ abläuft. Das Zwischenspeichern entlastet zwar die CDP-Endpunkte und verbessert die Verbindungslatenz, führt jedoch zu einem Zeitfenster, in dem ein kürzlich widerrufenes Zertifikat von einem Client, der eine zwischengespeicherte (und nun veraltete) CRL verwendet, möglicherweise noch akzeptiert wird. Dieser Kompromiss zwischen Aktualität und Leistung ist untrennbar mit der CRL-basierten Widerrufung verbunden und sollte bei Entscheidungen über die Häufigkeit der CRL-Veröffentlichung berücksichtigt werden.

Umfangreiche CRL-Downloads erhöhen zudem die Latenz während des ersten Verbindungsaufbaus, wenn noch keine zwischengespeicherte Kopie vorhanden ist, was sich auf die Benutzererfahrung und die Anwendungsleistung auswirken kann.

CRL-Überwachung und -Verwaltung

Warum die CRL-Überwachung so wichtig ist

Missmanagement kann schwerwiegende Folgen haben. Wenn Ihre CRL abgelaufen oder nicht erreichbar ist, werden alle Ihre Zertifikate sofort unbrauchbar. Eine einzige versäumte CRL-Veröffentlichung oder ein nicht erreichbarer CDP kann einen großflächigen Ausfall auslösen, der jeden Dienst betrifft, der auf Zertifikate dieser Zertifizierungsstelle angewiesen ist.

Was ist zu überwachen?

Eine wirksame CRL-Überwachung sollte folgende Aspekte umfassen:

• Reaktionsfähigkeit der Endpunkte: Stellen Sie sicher, dass alle CDP-URLs erreichbar sind und gültige CRL-Daten zurückgeben.
• Bevorstehende Ablaufdaten: Warnung, wenn sich der Zeitstempel für die „nächste Aktualisierung“ einer CRL nähert und noch kein Ersatz veröffentlicht wurde.
• Abgelaufene CRLs: Markieren Sie unverzüglich alle CRLs, deren „nächster Aktualisierungszeitpunkt“ überschritten wurde, ohne dass sie ersetzt wurden.

CRL-Generierung und -Automatisierung

Die Erstellung von CRLs kann manuell (auf Anforderung durch einen Administrator) oder automatisiert über verschiedene Mechanismen erfolgen:

• CRL-Aktualisierungs-Service-Worker: Hintergrundprozesse, die CRLs nach einem konfigurierten Zeitplan erstellen und veröffentlichen.
• Ereignisgesteuerte Erstellung: Automatische Veröffentlichung der CRL unmittelbar nach dem Widerruf eines Zertifikats.
• Unix-Cron-Jobs: Geplante Aufgaben, die in festgelegten Intervallen die Erstellung von CRLs auslösen.

Als bewährte Vorgehensweise sollten neu eingerichtete Zertifizierungsstellen (CAs) unmittelbar nach ihrer Einrichtung eine leere CRL veröffentlichen. Dadurch wird sichergestellt, dass vertrauende Parteien die Zertifikate der Zertifizierungsstelle vom ersten Tag an validieren können, noch bevor es zu Sperrungen gekommen ist.

Häufige Herausforderungen und Einschränkungen bei CRLs

Zwar sind CRLs nach wie vor ein grundlegender Sperrmechanismus in der PKI, doch sind sie mit bekannten betrieblichen Herausforderungen verbunden:

• Skalierbarkeit: CRL-Dateien werden mit jeder Sperrung größer. Bei großen Zertifizierungsstellen sind CRLs mit Millionen von Einträgen möglich, und das Herunterladen und Auswerten dieser Dateien wird ressourcenintensiv. Dies ist besonders problematisch für Geräte mit begrenzten Ressourcen wie Smartphones und IoT , die nur über begrenzten Speicher und begrenzte Rechenleistung verfügen.
• Latenz: Um den Status eines einzelnen Zertifikats zu überprüfen, muss die gesamte CRL heruntergeladen und analysiert werden. Im Gegensatz zu OCSP, das eine gezielte Antwort für ein einzelnes Zertifikat liefert, bieten CRLs keine Möglichkeit, einzelne Einträge abzufragen.
• Verbindungs-Overhead: Wenn keine aktuelle CRL-Kopie im Cache vorhanden ist, muss die vertrauende Partei die CRL während des anfänglichen TLS abrufen, was zu einer messbaren Verzögerung beim Verbindungsaufbau führt.
• Caching-Fenster: Die Zeitspanne zwischen den Veröffentlichungen von CRLs führt zu einem Zeitfenster, in dem ein widerrufenes Zertifikat von vertrauenden Parteien anhand einer zwischengespeicherten Kopie möglicherweise weiterhin akzeptiert wird. Kürzere Veröffentlichungsintervalle verkürzen dieses Zeitfenster, erhöhen jedoch die Belastung der Zertifizierungsstelle und des Netzwerks.

CRL-Best-Practices

Eine effektive Verwaltung von CRLs erfordert eine sorgfältige Planung und operative Disziplin. Die folgenden Vorgehensweisen befassen sich mit den häufigsten Fehlerquellen:

1. Legen Sie die Aktualisierungshäufigkeit entsprechend dem Risiko fest. CRLs von Zertifizierungsstellen sollten alle 24 bis 72 Stunden veröffentlicht werden. CRLs von Stammzertifizierungsstellen, bei denen die Signaturschlüssel offline aufbewahrt werden, können alle 3 bis 12 Monate veröffentlicht werden. Passen Sie die Häufigkeit an die Sensibilität der ausgestellten Zertifikate an.
2. Überwachen Sie CRL-Endpunkte proaktiv. Warten Sie nicht, bis es zu einem Ausfall kommt, um festzustellen, dass ein CDP nicht erreichbar ist oder eine CRL abgelaufen ist. Richten Sie eine automatisierte Überwachung ein, die die Verfügbarkeit der Endpunkte überprüft und bei bevorstehenden Ablaufdaten eine Warnmeldung ausgibt.
3. Automatisieren Sie die Erstellung von CRLs. Die manuelle Veröffentlichung von CRLs ist fehleranfällig und nicht skalierbar. Nutzen Sie geplante Aufgaben, Service Worker oder ereignisgesteuerte Automatisierung, um sicherzustellen, dass CRLs zuverlässig und pünktlich veröffentlicht werden.
4. Sorgen Sie für hohe Verfügbarkeit. CRL-Endpunkte sind Teil der kritischen Infrastruktur. Nutzen Sie CDNs, Webfarmen oder Webserver mit Lastenausgleich, um sicherzustellen, dass CDP-URLs auch bei Serverausfällen oder Traffic-Spitzen erreichbar bleiben.
5. Setzen Sie partitionierte CRLs in großem Maßstab ein. Wenn Ihre PKI große Mengen an Zertifikaten ausstellt, sollten Sie partitionierte CRLs verwenden, um die einzelnen CRL-Dateien in einer überschaubaren Größe zu halten.
6. Die CRL-Richtlinie sollte an die Sicherheitsanforderungen angepasst werden. Der Kompromiss zwischen der Aktualität der CRL und dem betrieblichen Aufwand sollte eine explizite strategische Entscheidung sein, die sich nach der Risikotoleranz der Organisation und der Sensibilität der durch die PKI geschützten Systeme richtet.
7. Berücksichtigen Sie das Caching-Verhalten. Beachten Sie, dass vertrauende Parteien CRLs bis zum Zeitstempel der „nächsten Aktualisierung“ zwischenspeichern. Berücksichtigen Sie dieses Caching-Fenster bei der Erstellung von Plänen zur Reaktion auf Vorfälle und bei Entscheidungen über die Dringlichkeit von Sperrungen.

Wie Keyfactor helfen Keyfactor

Die Verwaltung von CRLs und der Zertifikatssperrung in großem Maßstab erfordert sowohl eine leistungsfähige PKI-Infrastruktur als auch einen zentralen Überblick über den Sperrstatus in der gesamten Umgebung.

EJBCA Keyfactor ist eine voll ausgestattete CA-Plattform der Enterprise-Klasse, die vollständige Kontrolle über die Erstellung und Verteilung von CRLs bietet. EJBCA die manuelle und automatisierte Veröffentlichung von CRLs, partitionierte CRLs sowie die Erstellung von Delta-CRLs, konfigurierbare Einstellungen für CRL-Verteilungspunkte (CDP) und flexible Veröffentlichungsintervalle. Als Zertifizierungsplattform, die für die Ausstellung und den Widerruf von Zertifikaten zuständig ist, EJBCA PKI-Teams die direkte Kontrolle über den gesamten Widerrufslebenszyklus – von der Ausstellung bis zur Veröffentlichung der CRL.

Keyfactor Command bietet eine zentralisierte Transparenz- und Automatisierungsebene, die alle Zertifizierungsstellen (CAs) in der Umgebung umfasst. Command CRL- und OCSP-Endpunkte, versendet konfigurierbare E-Mail-Benachrichtigungen, wenn CRLs kurz vor dem Ablauf stehen, und ermöglicht die Echtzeit-Überwachung des Sperrstatus im gesamten Zertifikatsbestand. Für Unternehmen, die Zertifikate von mehreren Zertifizierungsstellen verwalten, Command die Sperrdaten aller Zertifizierungsstellen in einem einheitlichen Überwachungs-Dashboard und verhindert so, dass abgelaufene oder nicht erreichbare CRLs unbemerkt bleiben.

GemeinsamCommand EJBCA Keyfactor Command ein umfassendes Management des gesamten Zertifikatslebenszyklus: Erfassung, Überwachung, Ausstellung, Verlängerung und Sperrung – alles über eine einheitliche Plattform.