Erläuterung der CRL-Gründe: Zertifikatswiderruf in der PKI

Der Zertifikatswiderruf ist einer der wichtigsten, aber oft übersehenen Aspekte der Public-Key-Infrastruktur . Wenn ein Zertifikat vor seinem Ablaufdatum nicht mehr als vertrauenswürdig eingestuft werden kann, widerruft die ausstellende Zertifizierungsstelle (CA) es und veröffentlicht diesen Status über Mechanismen wie Zertifikatssperrlisten (CRLs) oder das Online Certificate Status Protocol (OCSP).

Der Widerrufsstatus signalisiert den vertrauenden Parteien, dass ein Zertifikat nicht mehr vertrauenswürdig ist. Ein Widerrufsgrundcode liefert Kontextinformationen, indem er den Grund erläutert. Diese Informationen werden in der in RFC 5280 definierten CRLReason-Erweiterung übermittelt.

Das Verständnis von CRL-Grundcodes hilft PKI-Administratoren, Sicherheitsteams, Auditoren und Compliance-Teams, zwischen einem routinemäßigen Ereignis im Zertifikatslebenszyklus und einem echten Sicherheitsvorfall zu unterscheiden. Dieser Blogbeitrag erläutert die Bedeutung der Codes, die in RFC 5280 definierten Werte, ihre Unterschiede zu ReasonFlags, die Einschränkungen durch öffentliche TLS-Richtlinien sowie die Vorgehensweisen, die die Nutzbarkeit von Widerrufsdaten gewährleisten.

Was sind CRL-Grundcodes?

Ein CRL-Grundcode ist ein standardisierter Wert, der in einem einzelnen CRL-Eintrag angegeben werden kann, um den Grund für den Widerruf eines Zertifikats zu dokumentieren. RFC 5280 definiert CRLReason als optionale Erweiterung eines CRL-Eintrags, der einem widerrufenen Zertifikat zugeordnet ist. Anstatt ein Zertifikat lediglich als ungültig zu kennzeichnen, kann die Zertifizierungsstelle somit den Grund dafür festhalten.

Diese Unterscheidung ist operativ bedeutsam. Ein Zertifikat, das aufgrund der Ersetzung durch ein neueres widerrufen wurde, erfordert eine ganz andere Reaktion als ein Zertifikat, dessen privater Schlüssel kompromittiert wurde. Da die Codes einem gemeinsamen Standard folgen, können Plattformen für das Zertifikatslebenszyklusmanagement , Überwachungssysteme und Sicherheitsworkflows Widerrufsereignisse in verschiedenen PKI-Umgebungen einheitlich verarbeiten.

CRL-Grundcodes gemäß RFC 5280

RFC 5280 definiert die CRLReason-Werte als ASN.1-Enumeration. Der numerische Code ist relevant, da er im CRL-Eintrag des Zertifikats erscheint.

Code	Grund	Bedeutung
0	nicht spezifiziert	Es wird kein konkreter Grund genannt.
1	Schlüsselkompromiss	Es ist bekannt oder wird vermutet, dass der private Schlüssel des Zertifikats kompromittiert wurde.
2	cACompromise	Es ist bekannt oder wird vermutet, dass der private Schlüssel der ausstellenden Zertifizierungsstelle kompromittiert wurde.
3	ZugehörigkeitGeändert	Der Name oder die Zugehörigkeitsangaben der betreffenden Person haben sich geändert.
4	abgelöst	Das Zertifikat wurde durch ein neueres Zertifikat ersetzt.
5	Einstellung der Operation	Das Zertifikat wird für seinen ursprünglichen Zweck nicht mehr benötigt.
6	ZertifikatHold	Vorübergehende Aussetzung des Zertifikats
8	RemoveFromCRL	Ein zuvor gesperrtes Zertifikat wird nicht mehr widerrufen; wird nur in Delta-CRLs verwendet.
9	Privileg entzogen	Eine im Zertifikat enthaltene Berechtigung wurde entzogen.
10	Ein Kompromiss	Es ist bekannt oder wird vermutet, dass ein Attributautoritätsschlüssel kompromittiert ist.

Der Wert 7 ist absichtlich reserviert und wird nicht verwendet, weshalb die Aufzählung von 6 auf 8 springt. Das Überspringen dieser Codes um eins, weil der Wert 7 fehlt, ist eine bekannte Fehlerquelle für CRL-Fehler in der Praxis. Daher sollte diese Lücke beachtet werden. Nicht jede Zertifizierungsstelle verwendet jeden Code, und öffentliche TLS-Systeme schränken die zulässigen Gründe ein, wie weiter unten erläutert.

Warum Widerrufsgründe wichtig sind

Der Widerrufsstatus gibt Auskunft darüber, ob ein Zertifikat noch vertrauenswürdig ist. Die Widerrufsgründe erklären, warum es nicht mehr vertrauenswürdig ist. Der Unterschied ist vergleichbar mit dem zwischen dem Austausch einer ablaufenden Kreditkarte gegen eine neue und der Meldung einer gestohlenen Karte: In beiden Fällen wird die alte Karte ungültig gemacht, aber nur die Meldung eines Kartendiebstahls signalisiert Betrug und erfordert ein sofortiges Handeln.

Wird ein Zertifikat aufgrund eines KeyCompromise-Vorfalls widerrufen, müssen Sicherheitsteams in der Regel mögliche Offenlegungen von Zugangsdaten untersuchen, betroffene Schlüssel rotieren und prüfen, ob Systeme kompromittiert wurden . Ein aufgrund von Ersatz widerrufenes Zertifikat hingegen spiegelt häufig die normale Lebenszyklusverwaltung wider, beispielsweise den Austausch eines ablaufenden Zertifikats gegen ein neues. Dieser Kontext verbessert die Reaktion auf Sicherheitsvorfälle, die Erstellung von Compliance-Berichten, die Durchführung von Audits, die Automatisierung des Lebenszyklus und die Ursachenanalyse.

Organisationen mit großen Zertifikatsbeständen nutzen diese Technologie, um Prioritäten bei der Behebung von Problemen zu setzen und den Betriebsaufwand zu reduzieren. In der Praxis sind präzise Metadaten zum Zertifikatssperrungsvorgang die Grundlage für die Messbarkeit und Nachvollziehbarkeit eines Zertifikatslebenszyklusprogramms.

CRLReason und ReasonFlags sind nicht dasselbe

Eines der häufigsten Missverständnisse im Bereich PKI ist die Annahme, dass CRLReason und ReasonFlags dasselbe sind. Das sind sie nicht.

CRLReason ist der Widerrufsgrund, der einem bestimmten widerrufenen Zertifikatseintrag in einer CRL zugeordnet ist und erklärt, warum dieses Zertifikat widerrufen wurde. ReasonFlags ist eine Bitfolge, die in der CRL-Verteilungspunkt -Erweiterung verwendet wird, um anzugeben, welche Kategorien von Widerrufsgründen ein bestimmter Verteilungspunkt abdeckt.

Komponente	Zweck
CRLReason	Erklärt, warum ein bestimmtes Zertifikat widerrufen wurde
Grundflags	Gibt an, welche Widerrufsgründe ein CRL-Verteilungspunkt abdeckt.

In der Praxis beschreibt CRLReason das Widerrufsereignis selbst, während ReasonFlags zertifikatsnutzenden Anwendungen und Systemen hilft, die relevanten Widerrufsinformationen zu finden. Diese Unterscheidung ist wichtig bei der Behebung von Validierungsproblemen, dem Entwurf einer PKI oder der Überprüfung eines Zertifikatsprofils. Die umfassendere Rolle vertrauenswürdiger Aussteller in dieser Kette wird in der Übersicht von Encryption Consulting zur Zertifizierungsstelle erläutert.

Wie sich CRL-Grundcodes auf TLS-Operationen auswirken

Obwohl RFC 5280 den gesamten Code definiert, werden in realen TLS- Umgebungen zusätzliche Richtlinien angewendet. Öffentlich vertrauenswürdige Zertifizierungsstellen unterliegen den Basisanforderungen und den Richtlinien des Browser-Root-Programms. Diese Regeln schränken die zulässigen Gründe für die Ausstellung öffentlich vertrauenswürdiger Zertifikate ein.

Zwei Einschränkungen sind zu beachten. Die Basisanforderungen (BR §4.9.1.1) besagen, dass der CRLReason für ein TLS-Zertifikat nicht unspezifiziert (0) sein darf; trifft kein spezifischer Grund zu, lässt die Zertifizierungsstelle die reasonCode-Erweiterung vollständig weg. Sie verbieten außerdem certificateHold (6) für TLS-Zertifikate, und einige Codes wie cACompromise, removeFromCRL und aACompromise sind für Endbenutzer-TLS-Zertifikate überhaupt nicht anwendbar. Im täglichen Gebrauch verbleiben somit fünf zulässige Grundcodes:

• keyCompromise signalisiert ein Sicherheitsereignis und löst in der Regel dringende Maßnahmen aus.
• „Ersetzt“ bedeutet, dass es sich um einen routinemäßigen Zertifikatsaustausch handelt.
• Die Meldung „cessationOfOperation“ erscheint, wenn ein Dienst oder eine Anwendung außer Betrieb genommen wird.
• affiliationChanged kommt zum Einsatz, wenn sich die Eigentumsverhältnisse oder die Autorisierung der Organisation ändern.
• privilegeWithdrawn wird von der Zertifizierungsstelle verwendet, wenn Anzeichen für einen Missbrauch des Zertifikats oder einen wesentlichen Verstoß gegen die Teilnehmervereinbarung vorliegen.

Moderne Widerrufsverfahren kombinieren CRLs, OCSP , Certificate Transparency Monitoring und immer kürzere Zertifikatsgültigkeitsdauern. Im April 2025 verabschiedete das CA/Browser Forum die Abstimmung SC-081v3 , die die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate bis zum 15. März 2029 von 398 auf 47 Tage reduziert. Die erste Obergrenze von 200 Tagen trat am 15. März 2026 in Kraft, gefolgt von einer weiteren Reduzierung auf 100 Tage am 15. März 2027 und einer endgültigen Obergrenze von 47 Tagen am 15. März 2029.

Im gleichen Zeitraum verkürzt sich das Zeitfenster für die Wiederverwendung von Domainvalidierungsdaten auf 10 Tage. Diese Änderungen machen die automatisierte Verwaltung des Zertifikatslebenszyklus unerlässlich. Die Browserbehandlung von Zertifikatssperrungen variiert, doch korrekte Sperrinformationen bleiben zentral für das Vertrauen in die PKI und erfordern dieselbe Sorgfalt, die während der gesamten Lebensdauer von TLS-Zertifikaten angewendet wird.

Häufige Fehler und Herausforderungen im Alltag

Viele Organisationen wählen standardmäßig für fast jede Sperrung die Option „nicht spezifiziert“. Das ist zwar technisch für private PKI zulässig, aber es entfernt den Kontext, der Untersuchungen, Berichterstattung und Automatisierung effektiv macht, und für öffentliche TLS ist es nicht einmal erlaubt.

Ein weiteres häufiges Problem ist das Missverständnis von certificateHold. Es wurde für die vorübergehende Sperrung und nicht für den dauerhaften Widerruf entwickelt. Obwohl es in RFC 5280 definiert ist, wird es in modernen Umgebungen selten verwendet und ist für öffentliche TLS-Zertifikate nicht zulässig. Teams verwechseln außerdem CRLReason mit ReasonFlags, was zu falschen Annahmen über die Verteilung und Verarbeitung von Widerrufsinformationen führt.

In regulierten Umgebungen führt die uneinheitliche Verwendung von Begründungscodes zu Problemen bei der Prüfung, da ein Prüfer nicht feststellen kann, ob ein Zertifikat aufgrund eines Sicherheitsvorfalls oder einer routinemäßigen administrativen Änderung widerrufen wurde.

Best Practices für die Sicherheit

Der Widerruf von Zertifikaten sollte als zentraler Bestandteil der Verwaltung des Zertifikatslebenszyklus und nicht als bloße Pflichterfüllung betrachtet werden. Beim Widerruf von Zertifikaten tragen einige wenige Vorgehensweisen dazu bei, die Vertrauenswürdigkeit und Nutzbarkeit der Daten zu gewährleisten.

• Verwenden Sie den genauesten verfügbaren Grund und lassen Sie bei öffentlichen TLS-Verbindungen den reasonCode weg, anstatt standardmäßig auf unspecified zu setzen.
• Dokumentieren Sie die Verfahren für den Widerruf von Schlüsseln im Zusammenhang mit Kompromittierungen, damit keyCompromise einheitlich und schnell angewendet wird.
• Führen Sie Prüfprotokolle für jede Widerrufsaktion.
• Schützen Sie CA-Signaturschlüssel mit starken Kontrollen, indem Sie ein FIPS 140-3 Stufe 3 validiert Hardware-Sicherheitsmodul Wo angebracht. Die Schlüsselverwaltungs- und HSM-Dienstleistungen von Encryption Consulting können Unternehmen bei der Auswahl, Bereitstellung und dem Betrieb der richtigen HSM-Infrastruktur für ihre PKI-Umgebung unterstützen.
• Überwachen Sie die CRL- und OCSP-Veröffentlichung, damit die Widerrufsinformationen für die vertrauenden Parteien verfügbar bleiben.

Genaue Metadaten zur Zertifikatssperrung stärken sowohl den Sicherheitsbetrieb als auch das Compliance-Reporting und helfen Teams, bei einem Zertifikatsvorfall schneller zu reagieren.

Wie Verschlüsselungsberatung helfen kann

Die Verwaltung des Zertifikatswiderrufs in einer großen IT-Landschaft wird komplexer, wenn ein Unternehmen mehrere Zertifizierungsstellen, Zertifikatstypen und Vertrauensdomänen betreibt. Encryption Consulting unterstützt Sie mit seinen Enterprise PKI Services bei der Konzeption, Implementierung und Verwaltung einer skalierbaren PKI . Diese umfasst die Steuerung des Zertifikatslebenszyklus, Widerrufsprozesse, die Überprüfung der CA-Architektur, die Einhaltung von Compliance-Vorgaben und bewährte Verfahren für den Betrieb, sodass der Widerruf sowohl Sicherheits- als auch Geschäftsziele unterstützt.

Für den täglichen Betrieb bietet CertSecure Manager eine zentrale Übersicht über Zertifikatsbestände, Ablaufereignisse, automatisierte Verlängerungsprozesse und den Status der Sperrendpunkte (CRL und OCSP) im gesamten Unternehmen. Da die Gültigkeitsdauer öffentlich vertrauenswürdiger Zertifikate immer kürzer wird und sich auf 47 Tage verkürzt, ist diese Automatisierung entscheidend, um zwischen routinemäßigen Verlängerungen und vermeidbaren Ausfällen zu unterscheiden.

Ob es um die Modernisierung einer bestehenden PKI oder den Aufbau einer neuen Vertrauensarchitektur geht, Encryption Consulting kann Ihnen dabei helfen, sichere, nachvollziehbare und betrieblich effiziente Widerrufsprozesse zu etablieren.

Fazit

CRL-Grundcodes mögen auf den ersten Blick unbedeutend erscheinen, erklären aber, warum Zertifikate widerrufen werden und wie eine Organisation darauf reagieren sollte. Der wichtigste Unterschied besteht darin, dass CRLReason den Grund für den Widerruf eines bestimmten Zertifikats angibt, während ReasonFlags festlegt, welche Widerrufsgründe ein CRL-Verteilungspunkt abdeckt. Eine Verwechslung der beiden führt zu Fehlern im PKI-Design, bei der Fehlerbehebung und in den Richtlinien.

Mit zunehmender Automatisierung des Zertifikatslebenszyklus gewinnen präzise Informationen zum Zertifikatssperrungsstatus für Sicherheitsbetrieb, Audits, Compliance und die Reaktion auf Sicherheitsvorfälle immer mehr an Bedeutung. Richtig eingesetzt, machen CRL-Grundcodes die Sperrung von einer einfachen Statusprüfung zu einem wichtigen Bestandteil des Vertrauensmanagements. Ein erster praktischer Schritt ist die Standardisierung der von Ihren Teams verwendeten Grundcodes und die Sicherstellung, dass diese sowohl RFC 5280 als auch den Richtlinien für Ihre öffentlichen Zertifikate entsprechen.