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

Funktionsweise

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

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. Wenn die Sperrliste ein Telefonbuch ist, ist OCSP somit die Auskunft, an welche gezielte spezifische Anfragen gesendet werden können.

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 Authority Information Access (AIA)-Attributs in einem ausgestellten Zertifikat angegeben oder global auf dem überprüfenden Computer konfiguriert werden. Die OCSP-Erweiterung befindet sich unter AIA, 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. Dieses Verhalten gilt somit für alle Windows-Anwendungen, welche die Microsoft CAPI für die Überprüfung von Zertifikaten verwenden.

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 Sperrstatus-Infrastruktur, da nicht garantiert werden kann, dass der Client letztendlich nicht doch auf die Sperrliste 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 zugrundeliegenden 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 (noch) nicht benötigt. Sollte künftig der Bedarf entstehen können, sehr viele Zertifikate in einem kurzen Zeitraum widerrufen zu müssen, wie es beim Heartbleed-Vorfall der Fall war, wäre die Sperrprüfung per Sperrlisten schnell an der Grenze ihrer 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 verwenden Adobe Reader und Adobe Acrobat 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 (die Microsoft CAPI) 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 / CAPI zwischengespeichert.

Diese Aussage betrifft Anwendungen, welche auf Windows die CryptoAPI / CAPI verwenden, wie beispielsweise Internet Explorer, Edge oder Google Chrome. Das Verhalten kann bei anderen Anwendungen (z.B. Mozilla Firefox) 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. Auch dieser Umstand widerspricht der Annahme einer Live-Sperrstatusüberprüfung.

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 und 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 (zwei Tage vor ihrem Ablauf) 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 (oder gegebenenfalls geskriptet) zu erneuern. Dieser manuelle Prozess ist wiederum ein Risiko für die Verfügbarkeit des Onlineresponders (siehe weiter unten).

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 (bzw. TLS) geschützt wird (HTTPS).

Dies ist theoretisch zwar möglich, bietet aber nur Nachteile, da der Sperrstatus des für SSL erforderlichen Webserver-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 hierzu auch 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" (Objektidentifizierer (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.

Status	Beschreibung
Good	Das Zertifikat befindet sich nicht auf einer dem OCSP Responder bekannten Sperrliste.
Revoked	Das Zertifikat befindet sich auf einer dem OCSP Responder bekannten Sperrliste.
Unknown	Das 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.

Verfügbarkeit des Onlineresponders

Anforderungen an die Verfügbarkeit

Die Anforderungen an die Verfügbarkeit des Onlineresponders hängen von verschiedenen Faktoren ab:

Verfügbarkeit alternativer Methoden zur Sperrstatusüberprüfung.
Use Cases, welche vom Sperrstatus abhängen.

Anwendungen, welche zur Sperrstatus die Microsoft CryptoAPI bzw. CAPI verwenden, fallen bei Nichtverfügbarkeit eines Onlineresponders auf die Sperrlisten zurück. Sind die zu überprüfenden Zertifikate somit ohne Sperrlistenverteilpunkte konfiguriert (somit OCSP-only) ist die Verfügbarkeit des Onlineresponders somit deutlich kritischer einzustufen.

Manche Anwendungen (beispielsweise Adobe Reader und Adobe Acrobat für Dokumentsignaturen) verwenden OCSP-Antworten als Zeitstempel (Time Stamp), um zu gewährleisten, dass Dokument-Signaturen auch nach Ablauf des verwendeten Signaturzertifikats weiterhin als gültig betrachtet werden.

Einflussgrößen auf die Verfügbarkeit

Folgende Faktoren haben Einfluss auf die Verfügbarkeit eines Onlineresponders:

Die Netzwerkinfrastruktur (z.B. Load Balancer, Netwerkkomponenten, Anbindung, Namensauflösung usw.).
Aufbau der Serverinfrastruktur (wird ein Cluster oder ein einzelner Server verwendet?).
Verfügbarkeit der Zertifizierungsstelle und ihrer privaten Schlüssel (Sowohl die verwendeten Sperrlisten als auch die Signaturzertifikate für die Onlineresponder müssen von dieser regelmäßig signiert werden).
Konfiguration der OCSP-Antwortsignatur-Zertifikatvorlage (Diese ist in der Standardkonfiguration für eine Gültigkeitsdauer von zwei Wochen und eine Erneuerung zwei Tage vor Ablauf konfiguriert.).

Somit bestünde in der Standard-Konfiguration und je nach Anwendungsfall selbst bei einer großzügigen Konfiguration der Sperrlistengültigkeitszeit und -Überlappung nur ein Zeitfenster von zwei Tagen bei einem (angenommenen) Zertifizierungsstellen-Ausfall bis zum Ausfall des Onlineresponders.

Die Zertifikatvorlage für die OCSP-Antwortsignatur

Die Standard-Zertifikatvorlage für die OCSP-Antwortsignatur ist auf eine Gültigkeitsdauer von nur zwei Wochen konfiguriert. Dieses kurze Zeitfenster hat den Hintergrund, dass OCSP-Antwortsignaturzertifikate keine Sperrstatusinformationen beinhalten dürfen und es entsprechend nicht möglich ist, ein kompromittiertes OCSP-Antwortsignaturzertifikat zu widerrufen.

Da das OCSP-Antwortsignaturzertifikat immer von der dazugehörigen Zertifizierungsstelle (dem gleichen Schlüssel, welcher zum Signieren des zu überprüfenden Zertifikats) ausgestellt sein muss, kann kein Autoenrollment für die Zertifikatbeantragung verwendet werden. Der Microsoft-Onlineresponder beinhaltet daher eine eigene Routine zur Zertifikatbeantragung. Er wendet das in der Zertifikatvorlage konfigurierte Zeitfenster für die Erneuerung des Zertifikats an. Eine höhere Resilienz kann somit dadurch erreicht werden, dieses Zeitfenster möglichst groß zu konfigurieren.

Weiterführende Links:

Externe Quellen

How Certificate Revocation Works (Microsoft)
RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP (Internet Engineering Task Force)
Online Certificate Status Protocol (Wikipedia)
What is the status of revocation checking in browsers? (Ryan Hurst)