Aus Sicht der Zertifizierungsstellen ist das Management von digitalen Zertifikaten nichts anderes wie das Pflegen von Listen mit „guten“ und „schlechten“ Zertifikaten. Diese Listen werden dann zur Verfügung gestellt, damit jeder Nutzer den Status eines Zertifikats abfragen kann. Wenn das geprüfte Zertifikat nicht in einer Liste aufgeführt ist, kann der Nutzer in den meisten Fällen davon ausgehen, dass es in Ordnung ist. Es gibt viele Methoden für die Veröffentlichung und Abfrage dieser Listen, aber nur wenige davon sind weit verbreitet. Das liegt vor allem daran, dass die Methoden langsam, fehleranfällig oder einfach nur kompliziert zu verstehen und umzusetzen sind.

Die einfachste Form der Widerrufsprüfung ist die Nutzung von Zertifikatssperrlisten (Certificate Revocation Lists, CRL). Dabei handelt es sich um eine von der Zertifizierungsstelle erstellte einfache Textdatei, die manuell (regelmäßig) auf das Gerät hochgeladen werden muss, dass die Widerrufsprüfungen durchführen soll.

Das authentifizierende Gerät (z. B. ein Webserver oder Application Delivery Controller, kurz ADC) überprüft diese Liste für jede Sitzung, die es authentifizieren muss. Wenn das vorgelegte Zertifikat gültig ist und nicht in dieser Liste erscheint, kann der Benutzer fortfahren.

Das CRLDP-Prüfverfahren funktioniert wie folgt:

  1. Der Client verbindet sich mit dem Standort und führt einen TLS/SSL-Handshake durch.
  2. ADC sendet Server-Zertifikat zurück.
  3. Der Client ermittelt den Standort der CRL und holt sie vom CA-Server ab.
  4. CA-Server sendet CRL an den Client zurück.
  5. Client prüft gesamte CRL auf übereinstimmenden Zertifizierungs-Hash.

CRLs sind technisch sehr einfach zu verwenden, aber in der Praxis schwierig umzusetzen. Sie werden oft nicht häufig genug aktualisiert und es ist mühsam, sie manuell in authentifizierende Geräte (wie die ADC) zu importieren. Außerdem können sie sehr umfangreich werden und es gibt möglicherweise mehrere CRL-Quellen, die Unternehmen berücksichtigen müssen.

Um den manuellen Schritt des Imports einer CRL-Datei zu vermeiden, kann ein CRL-Verteilungspunkt so konfiguriert werden, dass der Webserver (ADC) die Datei automatisch von einer Online-Quelle einlesen kann, normalerweise über HTTP(S) oder LDAP. Damit ist zwar ein Problem gelöst, die anderen bleiben jedoch bestehen. Eines der größeren Probleme ist, wörtlich genommen, die Größe der CRL selbst.

Die Studie mit dem Titel „Eine End-to-End-Messung des Widerrufs von Zertifikaten in der PKI des Internets“ zeigt, dass neue CRL-Dateien zwar nur einige Dutzend Bytes groß sein können, die durchschnittliche CRL-Datei vieler Zertifizierungsstellen jedoch 0,5 MByte und die größte über 7 MByte groß sein kann. In einer E-Commerce-Umgebung würde jeder Benutzer sehen, wie sein Webbrowser diese Liste manuell herunterlädt, um sicherzustellen, dass das Zertifikat der Website, mit der er sich verbindet, nicht widerrufen wurde.

Das Online-Zertifikatsstatusprotokoll (OCSP)

Das exponentielle Wachstum der Größe von CRL-Dateien machte eine andere Lösung erforderlich. OCSP wurde geschaffen, um dieses Problem zu lösen. Das Verfahren ähnelt dem der CRL-Prüfung, mit dem Unterschied, dass der Client nur noch den Status des jeweiligen Zertifikats abrufen muss, an dem er interessiert ist, und nicht mehr die gesamte Liste.

  1. Der OCSP-Überprüfungsprozess findet wie folgt statt:
  2. Der Client verbindet sich mit dem Standort und führt einen TLS/SSL-Handshake durch.
  3. ADC sendet Server-Zertifikat zurück.
  4. Client liest den Standort von OCSP und sendet Anfrage an CA.
  5. CA-Server sendet OCSP-Status an den Client zurück.

Auf diese Weise können Unternehmen den Status eines Zertifikats viel effizienter überprüfen. Allerdings gibt es immer noch ernsthafte Probleme mit diesem System:

  • Die Anzahl der Abfragen beim OCSP-Responder (CA-Server) kann hoch sein, da jeder Client den Status jedes Zertifikats überprüfen muss.
  • Es handelt sich um ein Leck in der Privatsphäre – der OCSP-Responder verfügt nun über ein potenzielles Protokoll jeder Client-IP und des Namens der Website, die er besuchen möchte.
  • Der gesamte Prozess ist immer noch langsam, da der Client eine weitere Reihe von Hin- und Rückreisen unternehmen muss, um eine Verbindung herzustellen und den Status eines Zertifikats abzufragen. Bei einer Verbindung mit hoher Latenz, z. B. einem schlechten Mobilfunknetz oder einer Satellitenverbindung, kann dies in jeder Richtung Hunderte von Millisekunden betragen.

Das Management von digitalen Zertifikaten aus Sicht der Zertifizierungsstellen besteht hauptsächlich darin Listen von „guten“ und „schlechten“-Zertifikaten zu pflegen, die den Status der Zertifikate anzeigen. Das passiert entweder durch das Überprüfen von Zertifikatssperrlisten (CRLs) oder das Online-Zertifikatsstatusprotokoll (OCSP). CRLs sind einfach in der Anwendung, aber schwer in der Praxis umzusetzen, da sie häufig nicht ausreichend aktualisiert werden und manuell in authentifizierende Geräte importiert werden müssen.

Das OCSP bietet dagegen eine effizientere Möglichkeit, den Status von Zertifikaten zu überprüfen, jedoch gibt es immer noch Herausforderungen, wie eine hohe Anzahl von Abfragen beim OCSP-Responder und Datenschutzbedenken. Die Wahl zwischen CRLs und OCSP hängt von den spezifischen Anforderungen und Herausforderungen des jeweiligen Unternehmens ab.

Jens Sabitzer ist Manager Solution Architect Central Europe bei Venafi.

Venafi