Grundlagen Onlineresponder (Online Certificate Status Protocol, OCSP)

Zertifikate verfügen in der Regel über die Erweiterung "CRL Distribution Points", anhand derer einer Anwendung mitgeteilt wird, wo die zum Zertifikat zugehörige Zertifikatsperrliste (Certificate Revocation List, CRL) zu finden ist.

Diese gleicht einem Telefonbuch: In ihr finden sich alle Seriennummern von von der Zertifizierungsstelle zurückgerufenen (und noch zeitgültigen) Zertifikaten. Jede Anwendung, die den Sperrstatus überprüft, muss die gesamte Sperrliste herunterladen und auswerten.

Mit zunehmender Größe wird dieses Verfahren immer ineffizienter. Als Faustregel gilt, dass 100.000 zurückgerufene Zertifikate bereits ca. 5 MB Dateigröße für die Sperrliste entsprechen.

Hierfür wurde (federführend von der Firma ValiCert) das Online Certificate Status Protocol (OCSP) entwickelt: Es gleicht einer Auskunft, bei der Anwendungen den Sperrstatus für einzelne Zertifikate anfragen können, und somit der Bedarf entfällt, die gesamte CRL herunterladen zu müssen. OCSP ist im RFC 6960 spezifiziert.

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ät 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.

Funktionsweise

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

OCSP greift in der Microsoft-Implementierung wiederum auf CRLs als Datenbasis zurück. Somit besteht keine direkte Verbindung zur Zertifizierungsstellen-Datenbank, und der Responder kann in der Standardeinstellung keine Aussage treffen ob ein angefragtes Zertifikat auch tatsächlich von der Zertifizierungsstelle ausgestellt wurde (Deterministisches "Good").

Die Verfügbarkeit von OCSP kann innerhalb des AIA-Attributs in einem Zertifikat angegeben oder global auf dem überprüfenden Computer konfiguriert werden. Die OCSP-Erweiterung befindet sich unter Authority Information Access, da es sich auch beim Onlineresponder um eine Authority handelt (Validation Authority, VA).

Ist eine OCSP-Adresse im zu überprüfenden Zertifikat vorhanden, wird diese von modernen Windows-Betriebssystemen gegenüber Sperrlisten bevorzugt.

Nachteile bei Verwendung von OCSP

OCSP bringt neben seinen Vorteilen jedoch auch einige Nachteile mit sich:

  • OCSP wird aufgrund der vermeintlich in Echtzeit erfolgenden Sperrprüfung oft als Sicherheitsmerkmal verstanden, es ist aber lediglich ein Werkzeug zur Leistungssteigerung der Sperrungs-Infrastruktur, da nicht garantiert werden kann, dass der Client letztendlich nicht doch auf die Sperrliste mit deutlich längeren Wartezeiten zurückgreift. Abgesehen davon haben auch OCSP-Antworten einen Gültigkeitszeitraum, genau wie eine Sperrliste. Das Enddatum für diesen Gültigkeitszeitraum wird 1:1 aus der Sperrliste übernommen.
  • OCSP ist standortabhängig, d.h. in einer verteilten Infrastruktur würden sich alle Clients über potentiell langsame und ausfallgefährdete WAN-Leitungen zum zentralen Online-Responder verbinden, was effektiv sogar zu einer Erhöhung der CRL-Prüfzeit sowie Netzwerklast führen kann.

Es kann jedoch durchaus eine Überlegung wert sein, OCSP zu implementieren, obwohl man es vom derzeitigen Standpunkt aus betrachtet nicht benötigt. Sollte künftig der Bedarf entstehen können, sehr viele Zertifikate in einem kurzen Zeitraum zu müssen, wie es beim Heartbleed-Vorfall der Fall war, wäre die Sperrprüfung per Sperrlisten schnell an der Grenze ihre Leistungsfähigkeit angelangt.

Zur Sinnhaftigkeit der Verwendung von OCSP

OCSP ist ein zusätzlicher IT-Dienst, der personelle, technische und finanzielle Ressourcen bindet. In Anbetracht der Tatsache, dass eine (vielfach gewünschte) "Live"-Sperrung nicht realisierbar ist, stellt sich die Frage, wann der Einsatz von OCSP sinnvoll ist.

Gründe hierfür können sein:

  • Auditierung, wenn richtig gemacht (siehe Artikel "Domänencontroller (oder andere Teilnehmer) zwingen, einen Onlineresponder (OCSP) zu verwenden" für ein Anwendungsbeispiel).
  • Performance bei einer großen Menge (zu erwartender) widerrufener Zertifikate und entsprechend großen Zertifikatsperrlisten. In den meisten Umgebungen werden diese Größen in der Praxis jedoch nie erreicht werden.
  • Als Notfalloption. Sollte künftig der Bedarf entstehen, eine große Menge von Zertifikaten auf einmal widerrufen zu müssen, wie es beispielsweise bei der Heartbleed-Sicherheitslücke der Fall war. Aber wie bereits erwähnt sprengen die meisten Umgebungen den Break-Even Punkt eher nicht, an dem OCSP effizienter ist als eine Sperrliste.
  • Anwendungs-spezifische Eigenheiten können den Einsatz eines Onlineresponders sinnvoll machen: Beispielsweise verwendet der Adobe Reader bei der Erstellung von Dokumentsignaturen die OCSP-Antwort (falls vorhanden) für das Signaturzertifikat zum Zeitpunkt der Signatur als Nachweis, dass das Zertifikat zu diesem Zeitpunkt gültig war.

Bitte auch beachten, dass Google Chrome und der auf Chromium basierende Microsoft Edge (Codename Anaheim) in der Standardeinstellung ohnehin keine Sperrstatusüberprüfung vornehmen.

Fallstricke

Es kann aufgrund verschiedener Einflussfaktoren nicht garantiert werden, dass OCSP verwendet wird.

Zu diesen gehören:

  • Magic Number
  • Client-Implementierungen oder Einstellungen, die eventuell den Zertifikatinhalt überstimmen

Magic Number

Die Magic Number ist proprietär für die Implementierung von OCSP im Windows-Ökosystem.

Microsoft Windows bietet die Besonderheit einer "Magic Number", also einem Zähler, der für jede Zertifizierungsstelle hochgezählt wird. Wird der Zähler überschritten und besitzt das Zertifikat auch einen Sperrlistenverteilpunkt (CRL Distribution Point, CDP), wird aus Effizienzgründen für künftige Anfragen dieser verwendet. Siehe Artikel "Die "Magic Number" für den Onlineresponder konfigurieren".

Sperrinformationen sind nicht "Live": der clientseitige Cache

Sowohl CRLs als auch OCSP-Antworten werden für den Zeitraum ihrer Gültigkeit von der Microsoft CryptoAPI zwischengespeichert.

Diese Aussage betrifft Anwendungen, welche auf Windows die CryptoAPI verwenden, wie beispielsweise Internet Explorer, Edge oder Google Chrome. Das Verhalten kann bei anderen Anwendungen oder Betriebssystemen allerdings abweichen.

Auf Windows-Betriebssystemen gibt es zwei Arten von Zwischenspeichern (Caches) für Sperrinformationen:

  • Festplatten-Cache. Dieser Cache kann von allen Anwendungen benutzt werden und ist persistent, d.h. auch nach einem Neustart des Computers verfügbar.
  • Arbeitsspeicher-Cache. Dieser Cache ist Anwendungs-spezifisch und nur während der Laufzeit der Anwendung vorhanden. Wird die Anwendung beendet, wird auch dieser Cache gelöscht.

Siehe hierzu auch Artikel "Den Adress-Zwischenspeicher für Sperrlisten (CRL URL Cache) einsehen und löschen".

OCSP ist nicht als Sicherheits- sondern als Effizienz- und somit Performance-Feature entwickelt worden. Die OCSP-Antwort ist (in der Microsoft-Implementierung) exakt genau so lange gültig wie die ihr zugrundeliegende Sperrliste.

Sperrinformationen sind nicht "Live": der serverseitige Cache

Aus Effizienzgründen ist dem Microsoft Onlineresponder ein Cache im IIS-Webserver vorgeschaltet, der einmal signierte OCSP-Antworten während ihrer Gültigkeitszeit vorhält, damit sie bei weiteren Anfragen für das gleiche Zertifikat nicht erneut signiert werden müssen und Last auf dem Server und ggfs. dem eventuell vorhandenen Hardware Security Modul (HSM) erzeugen.

Aussagekraft der OCSP-Antworten

Da der Microsoft Onlineresponder auf Sperrlisten als Datenbasis zurückgreift, liegen ihm keine Informationen darüber vor, ob ein angefragtes Zertifikat, für das kein Sperrstatus ermittelt werden konnte, auch tatsächlich von der Zertifizierungsstelle ausgestellt wurde in in deren Datenbank auffindbar ist.

Es besteht allerdings die Möglichkeit, die Seriennummern der zu prüfenden Zertifikate zusätzlich gegen eine Liste von der Zertifizierungsstelle ausgestellter Zertifikate zu überprüfen, um somit auch unter direkter Verwendung des privaten Schlüssels (siehe Artikel "Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle") der Zertifizierungsstelle ausgestellt Zertifikate zu erkennen und eventuell eine Alarmierung auszulösen.

Siehe Artikel "Deterministisches "Good" für den Onlineresponder (OCSP) konfigurieren" für weitere Informationen.

OCSP-Antwortsignaturzertifikate können nicht widerrufen werden

Das OCSP-Signaturzertifikat darf keine Sperrstatusinformationen beinhalten dürfen, um eine Loop-Situation zu vermeiden (der Sperrstatus würde schließlich wieder per OCSP geprüft).

Daher handelt es sich bei den OCSP Antwortsignaturzertifikaten um besonders schützenswertes Zertifikate, die entweder mit einem Hardware Security Modul (HSM) geschützt werden oder wenigstens eine sehr kurze Zertifikatlaufzeit besitzen sollten.

In der Standardeinstellung des Microsoft Online Responders sind Signaturzertifikate deshalb nur 14 Tage gültig und werden automatisch vom Onlineresponder-Dienst erneuert.

Der Onlineresponder sollte, um sinnvoll verwaltet werden zu können, Domänenmitglied sein

Hier zeigt sich ein weiterer Nachteil: wenn die Onlineresponder-Server nicht im gleichen Active Directory beheimatet sein sollen wie die Zertifizierungsstellen (sind sie es, stellt man bei mit dem Internet verbundenen Onlinerespondern eine Brücke vom Internet zu den Online-Zertifizierungsstellen her), können die OCSP-Antwortsignaturzertifikate nicht automatisch erneuert werden. Eine manuelle Erneuerung im zweiwöchigen Rhytmus ist auch nicht praktikabel.

Auch wenn Hardware Security Module eingesetzt werden, sollte die Gültigkeit eines OCSP-Antwortsignaturzertifikats nicht mehr als einige Monate betragen. Man kommt also nicht darum herum, die Zertifikate in diesem Fall regelmäßig manuell zu erneuern. Dieser manuelle Prozess ist wiederum ein Risiko für die Verfügbarkeit des Onlineresponders.

HTTPS ist möglich, aber nicht sinnvoll

OCSP-Anfragen werden über das HTTP Protokoll übertragen. Oft ist aus Compliance-Gründen gewünscht, dass jeglicher HTTP-Datenverkehr per SSL geschützt wird.

Dies ist theoretisch zwar möglich, bietet aber nur Nachteile, da der Sperrstatus des für SSL erforderlichen SSL-Zertifikats wiederum zu prüfen wäre, und hier letztendlich kein SSL verwendet werden kann. Vorteile entstehen keine, da keine vertraulichen Informationen übermittelt werden. Ein Manipulationsschutz ist dadurch gegeben, dass OCSP-Antworten durch den Onlineresponder mittels des OCSP-Antwortsignaturzertifikats signiert sind.

Siehe Artikel "Verwenden von HTTP über Transport Layer Security (HTTPS) für die Sperrlistenverteilungspunkte (CDP) und den Onlineresponder (OCSP)" für weitere Informationen.

Ablauf einer OCSP-Kommunikation

Prüft eine OCSP-fähige Anwendung den Sperrstatus eines Zertifikats, wertet sie dessen Authority Information Access (AIA) Erweiterung aus. Befindet sich dort ein Eintrag vom Typ "On-line Certificate Status Protocol" (OID 1.3.6.1.5.5.7.48.1), wird anschließend die dort hinterlegte URL mit einer OCSP-Anfrage aufgerufen.

Die Kommunikation mit dem Onlineresponder erfolgt via HTTP und ganz bewusst ohne SSL. Hierbei kann sowohl die POST als auch die GET Methode verwendet werden.

HTTP-based OCSP requests can use either the GET or the POST method to submit their requests.

https://datatracker.ietf.org/doc/html/rfc6960#appendix-A.1

Die OCSP-Anfrage beinhaltet den "Name Hash" und den "Key Hash" (da sowohl "Name matching" als auch "Key matching" möglich sind, siehe hierzu "Grundlagen: Auffinden von Zertifikaten und Validierung des Zertifizierungspfades") der ausstellenden Zertifizierungsstelle sowie die Seriennummer des angefragten Zertifikats.

Sofern dem Onlineresponder die ausstellende Zertifizierungsstelle bekannt ist, überprüft er die zugrundeliegende Zertifikatsperrliste der Zertifizierungsstelle, ob die Seriennummer des angefragten Zertifikats dort eingetragen ist.

Die OCSP-Antwort wird mit dem Signaturzertifikat des Onlineresponders signiert. Das Signaturzertifikat muss vom gleichen (Zertifizierungsstellen-)Schlüssel signiert sein wie das zu überprüfende Zertifikat, damit die OCSP-Antwort vom anfragenden System akzeptiert wird.

Die signierte Antwort des Onlineresponders beinhaltet den Status sowie die Gültigkeitszeit der OCSP-Antwort.

StatusBeschreibung
GoodDas Zertifikat befindet sich nicht auf einer dem OCSP Responder bekannten Sperrliste.
RevokedDas Zertifikat befindet sich auf einer dem OCSP Responder bekannten Sperrliste.
UnknownDas Zertifikat konnte keiner dem OCSP-Responder bekannten Zertifizierungsstelle zugeordnet werden oder wurde nicht von einer solchen ausgestellt.

Wirft man einen Blick in die zugrundeliegende Sperrliste der Zertifizierungsstelle, wird man die exakt gleichen Daten für Beginn und Ablauf vorfinden.

Bitte darauf achten, dass die Zeiten im gezeigten Shelldialog lokalisiert sind, in der OCSP-Antwort jedoch die UTC-Zeiten angegeben sind.

Weiterführende Links:

Externe Quellen