Grundlagen: Überprüfung des Sperrstatus von Zertifikaten

Soll ein gültiges, noch nicht abgelaufenes Zertifikat aus dem Verkehr gezogen werden, muss es widerrufen werden. Hierfür pflegen die Zertifizierungsstellen entsprechende Sperrlisten, in welchen die digitalen Fingerabdrücke der widerrufenen Zertifikate aufgelistet sind. Sie müssen bei der Gültigkeitsprüfung abgefragt werden.

Mitunter ist es erforderlich, dass ein von einer Zertifizierungsstelle ausgestelltes Zertifikat bereits vor dessen Ablaufdatum aus dem Verkehr gezogen werden muss. Um dies zu ermöglichen, hält eine Zertifizierungsstelle eine Sperrliste vor. Hierbei handelt es sich um eine signierte Datei mit einem relativ kurzen Ablaufdatum, welches in Kombination mit dem Zertifikat zur Überprüfung der Gültigkeit herangezogen wird.

Sperrlisten (Certificate Revocation Lists, CRL)

Damit überprüft werden kann, ob die von einer PKI ausgestellten Zertifikate noch für die Verwendung freigegeben sind, muss diese Information den Kommunikationspartnern zur Verfügung gestellt werden. Wird ein Zertifikat z.B. aufgrund eines Diebstahls widerrufen bzw. gesperrt, wird dessen Seriennummer in einer Sperrliste (engl. Certificate Revocation List, CRL) hinterlegt.

Für das Widerrufen von Zertifikaten können die folgenden Gründe angegeben werden:

CodeBezeichnungBeschreibung
0UnspecifiedDies ist die Standardeinstellung und gibt an, dass es keinen speziellen Grund für den Widerruf gibt.
1Key CompromiseDer private Schlüssel eines Zertifikats wurde entwendet oder anderweitig unbefugten Dritten bekannt.
2CA CompromiseDer private Schlüssel der Zertifizierungsstelle wurde entwendet oder anderweitig unbefugten Dritten bekannt.
3Affiliation ChangedWenn sich der Inhalt des Zertifikats (z.B. der Name des Benutzers) geändert hat, muss ein neues Zertifikat ausgestellt werden.
4SupersededDas widerrufene Zertifikat wurde durch ein neues Zertifikat ersetzt.
5Cessation of OperationDer Betrieb des zum Zertifikate gehörenden Dienstes wurde eingestellt, etwa weil es einen neuen Dienst unter anderem Namen gibt.
6Certificate HoldDas Zertifikat wird vorübergebend widerrufen. Dieser Sperrungstyp ist der einzige, bei dem die Sperrung nachträglich wieder rückgängig gemacht werden kann.
8Remove from CRLWurde ein Zertifikat mit Grund "Certificate Hold" widerrufen und werden Deltasperrlisten verwendet, wird das entsperrte Zertifikat mit diesem Code in der Deltasperrliste geführt bis der Eintrag in der Haupt-Sperrliste entfällt.
-1UnrevokeWurde ein Zertifikat mit Grund "Certificate Hold" widerrufen, kann mit diesem Code eine Entsperrung per Kommandozeile erfolgen. Ebenso wird im Audit-Ereignis 4870 die Rückgängigmachung einer Zertifikatsperrung mit diesem Code kenntlich gemacht.

Die durchgehende Verfügbarkeit der CRL ist deutlich wichtiger als die der CA selbst: Muss der Sperrstatus eines Zertifikats von einem Computer überprüft werden, und ist eine gültige CRL zu diesem Zeitpunkt nicht verfügbar, schlägt die Prüfung fehl. Dies ist insbesondere aufgrund der sehr kurzen Gültigkeitszeiträume der CRL (in der Regel wenige Tage) äußerst kritisch.

Zur Ermittlung der zeitlichen Gültigkeit einer CRL stehen bis zu drei Felder zur Verfügung:

Bezeichnung (englisch)Beschreibung
This UpdateDieses Feld enthält das Datum, an welchem die Sperrliste signiert wurde, und damit dessen Gültigkeitszeitraum beginnt. Microsoft-Zertifizierungsstellen setzen den Wert zehn Minuten vor die aktuelle Uhrzeit, um Differenzen der Systemzeit (engl. "Clock Skew") der verschiedenen Teilnehmer auszugleichen.
Next UpdateDieses Feld enthält das Datum, an welchem die Sperrliste ungültig wird und durch eine neue Sperrliste ersetzt werden muss. Microsoft-Zertifizierungsstellen setzen den Wert zehn Minuten in die Zukunft, um Differenzen der Systemzeit der verschiedenen Teilnehmer auszugleichen.
Next Publishing DateDieses optionale Feld enthält das Datum, an welchem eine neue Sperrliste durch die Zertifizierungsstelle ausgestellt werden soll. Clients, die die alte Sperrliste noch in ihrem Cache haben, können diese bis zum effektiven Ablaufdatum ("Next Update") weiterhin verwenden, haben aber die Möglichkeit, bereits eine neue Sperrliste herunterzuladen (diese Funktion wird Pre-Fetching genannt). Die Verwendung dieses Feldes bei der Ausstellung von Sperrlisten wird auch CRL-Überlappung (CRL Overlapping) genannt.

Die "Next Publishing Date" Erweiterung der Zertifikatsperrliste ist proprietär für die Microsoft-Zertifizierungsstelle. Aus diesem Grund ist sie als nicht kritisch markiert, da sie nicht von allen Anwendungen korrekt interpretiert wird.

Der Speicherort, von dem die aktuelle CRL bezogen werden kann (z.B. ein Webserver) wird über das CDP-Attribut (engl. Certificate Distribution Point) innerhalb der Zertifikate bekanntgegeben.

Ein deutlicher Nachteil der Verwendung von CRLs ist, dass sie mit der Zeit sehr groß werden können, wenn viele Zertifikate widerrufen werden. Eine CRL sollte aus Gründen der Aktualität und somit letztendlich der Sicherheit einen möglichst kurzen Gültigkeitszeitraum (oft nur wenige Tage) haben.

Die CRLs müssen bei jeder Aktualisierung von allen Systemen und Anwendungen, die eine Sperrlistenprüfung durchführen, heruntergeladen werden, was sich mit zunehmendem Wachstum der CRL in der Auslastung des Netzwerks und entsprechenden Wartezeiten bei der Validierung von Zertifikaten bemerkbar machen kann.

Die Microsoft-Zertifizierungsstelle entfernt die Seriennummern abgelaufener Zertifikate nach deren Ablauf aus den ausgestellten Sperrlisten, um deren Größe möglicht gering zu halten.

Die Microsoft-Zertifizierungsstelle hält alle noch nicht abgelaufenen Zertifikatsperrlisten in der Zertifizierungsstellen-Datenbank vor. Eine zu häufige Ausstellung von Zertifikatsperrlisten kann sich somit auf die Größe der Zertifizierungsstellen-Datenbank auswirken.

Dieses Problem kann zum Teil mit Delta CRLs umgangen werden. Diese Dateien werden in kürzeren Abständen zusätzlich zu einer regulären CRL (der Base CRL) erzeugt und enthalten lediglich die Änderungen seit der letzten Veröffentlichung der Base CRL. Durch die kurze Laufzeit der Delta CRLs muss man aber auch eine deutlich reduzierte Reaktionszeit bei einem Ausfall der Zertifizierungsstelle einplanen, sodass der Einsatz von Delta CRLs nur dann empfohlen werden kann, wenn eine entsprechende personelle Abdeckung sowie geeignete Notfallmaßnahmen definiert sind.

Ein generelles Problem von CRLs ist, dass sie ständig im Zugriff gehalten werden müssen. Üblicherweise speichern Clients eine CRL zwar zwischen, jedoch erhöht sich insbesondere durch kürzere Gültigkeitszeiträume aufgrund von Delta CRLs auch die Anzahl der Erneuerungen dieses Caches. Kann ein Client keine aktuelle CRL herunterladen, weil der CDP zu diesem Zeitpunkt nicht verfügbar ist, und ist die Kopie im Cache abgelaufen, wird das zu überprüfende Zertifikat als nicht vertrauenswürdig eingestuft.

Aufgrund dieser Problematik sind einige Browserhersteller mittlerweile sogar dazu übergegangen, den Sperrstatus von digitalen Zertifikaten im Internet nicht mehr durch ihre Produkte überprüfen zu lassen, wenn die CRLs nicht abgerufen werden können. Dies stellt in einer hoch sicherheitskritischen Unternehmensumgebung jedoch keine Option dar.

Online Certificate Status Protocol (OCSP)

Eine Alternative zu Sperrlisten stellt das Online-Zertifikatsstatusprotokoll (engl. Online Certificate Status Protocol, OCSP) dar.

Anstelle des Downloads einer (vermeintlich großen) CRL fragt ein Client für jedes zu prüfende Zertifikat bei einem sog. Online-Responder den Sperrstatus ab und erhält eine signierte Antwort, ob das Zertifikat gesperrt wurde oder nicht.

Für eine ausführliche Beschreibung siehe Artikel "Grundlagen Onlineresponder (Online Certificate Status Protocol, OCSP)".

Weiterführende Links:

Externe Quellen

13 Gedanken zu „Grundlagen: Überprüfung des Sperrstatus von Zertifikaten“

Kommentare sind geschlossen.

de_DEDeutsch