Was ist OCSP (Online Certificate Status Protocol)?

Vor der Einführung von OCSP bestand die wichtigste Methode zur Überprüfung des Sperrstatus darin, eineZertifikatssperrliste (CRL) herunterzuladen – eine regelmäßig veröffentlichte Datei, die die Seriennummern aller gesperrten Zertifikate enthält. CRLs funktionieren zwar, erfordern jedoch, dass der Client die gesamte Liste herunterlädt, auswertet und auf Übereinstimmungen überprüft. Mit der zunehmenden Verbreitung von PKI- Implementierungen wuchs auch der Umfang dieser Listen, was zu Problemen hinsichtlich Bandbreite und Latenz führte, die eine Echtzeit-Validierung in vielen Umgebungen unpraktikabel machten.

OCSP löst dieses Problem, indem es das Modell umkehrt. Anstatt eine vollständige Liste herunterzuladen, sendet der Client eine kompakte Anfrage zum Status eines einzelnen Zertifikats. Der OCSP-Responder gibt eine digital signierte Antwort zurück, die bestätigt, ob dieses Zertifikat gültig, widerrufen oder unbekannt ist. Das Ergebnis ist eine schnellere und effizientere Überprüfung auf widerrufene Zertifikate, die sich an moderne Umgebungen anpassen lässt.

Einen ausführlichen Vergleich der beiden Ansätze, einschließlich der jeweiligen Anwendungsfälle, finden Sie im Artikel„CRL vs. OCSP: Was Sie wissen müssen“.

So funktioniert OCSP

Eine OCSP-Transaktion folgt einem einfachen Anfrage- und Antwortmuster. Wenn ein Client (z. B. ein Browser, ein VPN-Gateway oder eine Anwendung) auf ein Zertifikat stößt, das er validieren muss, ermittelt er die OCSP-Responder-URL, die in der AIA-Erweiterung (Authority Information Access) des Zertifikats eingebettet ist. Der Client erstellt daraufhin eine Anfrage, sendet diese über HTTP an diese URL und erhält eine signierte Antwort.

Hier ist die Schritt-für-Schritt-Anleitung:

1. Der Client erhältwährend eines TLS oder eines anderen PKI-Vorgangs ein Zertifikat.
2. Der Client entnimmt die URL des OCSP-Respondersaus der AIA-Erweiterung des Zertifikats.
3. Der Client erstellt eine OCSP-Anfrage, die die Identifikationsdaten des Zertifikats enthält.
4. Der OCSP-Responder überprüft den Status des Zertifikatsanhand seiner Quelle für Sperrdaten.
5. Der Responder gibt eine digital signierte Antwortmit dem aktuellen Status des Zertifikats zurück.

Der gesamte Austausch ist in der Regel innerhalb von Millisekunden abgeschlossen, sodass der Client Sperrdaten nahezu in Echtzeit erhält, ohne dass der Aufwand für das Herunterladen einer vollständigen CRL entsteht.

Die OCSP-Anfrage und -Antwort

Eine OCSP-Anfrage identifiziert das betreffende Zertifikat mithilfe einer in RFC 6960 definierten CertID-Struktur. Diese Struktur enthält vier Felder:

• Hash-Algorithmus:Der Algorithmus, der zur Berechnung der nachstehenden Hashwerte verwendet wird (in der Regel SHA-1 oder SHA-256).
• Hash des Ausstellernamens:Ein Hash des Distinguished Name der ausstellenden Zertifizierungsstelle.
• Hash des Ausstellerschlüssels:Ein Hash des öffentlichen Schlüssels der ausstellenden Zertifizierungsstelle.
• Seriennummer:Die eindeutige Seriennummer des zu prüfenden Zertifikats.

Zusammen ermöglichen diese Felder die eindeutige Identifizierung eines bestimmten Zertifikats, ohne dass der Client das vollständige Zertifikat an den Empfänger senden muss.

Der OCSP-Responder wertet die Anfrage aus und gibt eine signierte Antwort zurück, die einen von drei Statuswerten enthält:

• Gut:Das Zertifikat ist gültig und wurde nicht widerrufen.
• Widerrufen:Das Zertifikat wurde widerrufen, und die Antwort enthält den Zeitpunkt des Widerrufs sowie (optional) den Grund dafür.
• Unbekannt:Der Antwortgeber verfügt über keine Informationen zu dem angeforderten Zertifikat.

Jede Antwort enthält außerdem Zeitstempel: „producedAt“ (Zeitpunkt der Generierung der Antwort), „thisUpdate“ (Zeitpunkt der letzten Statusbestätigung) und „nextUpdate“ (Zeitpunkt, zu dem der Client erneut nachsehen sollte). Anhand dieser Zeitstempel können Clients Antworten zwischenspeichern und deren Aktualität bestimmen.

Wenn der Responder die Anfrage nicht verarbeiten kann, gibt er einen Fehlerstatuscode zurück. Zu den gängigen Codes gehören MALFORMED_REQUEST (die Anfrage konnte nicht analysiert werden), INTERNAL_ERROR (beim Responder ist ein Problem aufgetreten), TRY_LATER (der Responder ist vorübergehend nicht verfügbar) und UNAUTHORIZED (der Client ist nicht berechtigt, diesen Responder abzufragen).

Was ist ein OCSP-Responder?

Ein OCSP-Responder ist ein Server, der Anfragen zum Zertifikatsstatus entgegennimmt und eine digital signierte Antwort zurückgibt, aus der hervorgeht, ob ein bestimmtes Zertifikat gültig, widerrufen oder von unbekanntem Status ist.Der Responder wird von der Zertifizierungsstelle, die das Zertifikat ausgestellt hat,oder in deren Auftrag betrieben.

Es gibt zwei Modelle für Ersthelfer:

• CA-integrierter Responder:Die CA selbst signiert OCSP-Antworten mit ihrem eigenen privaten Schlüssel. Dies ist das einfachste Modell, setzt jedoch voraus, dass der Signaturschlüssel der CA online und zugänglich ist, was sicherheitstechnische Überlegungen mit sich bringt.
• Beauftragter Responder:Die Zertifizierungsstelle stellt einem dedizierten Responder ein separates OCSP-Signaturzertifikat aus. Dieses Zertifikat muss die Schlüsselverwendung „Digitale Signatur“ und die erweiterte Schlüsselverwendung „OCSP-Signierer“ enthalten. Durch beauftragte Responder kann der Stamm- oder Zwischenzertifikatschlüssel der Zertifizierungsstelle offline bleiben, während weiterhin Statusinformationen in Echtzeit bereitgestellt werden.

In PKI-Umgebungen von Unternehmen kann ein einzelner OCSP-Responder Anfragen für mehrere Zertifizierungsstellen (CAs) beantworten. Unternehmen, die eine hohe Verfügbarkeit benötigen, setzen in der Regel mehrere Responder-Knoten ein, von denen jeder über eine eigene Kopie der Sperrdaten verfügt und hinter einem Load Balancer betrieben wird. Diese Architektur stellt sicher, dass die Zertifikatsvalidierung auch dann fortgesetzt wird, wenn einzelne Knoten ausfallen.

OCSP-Stapling erklärt

Beim Standard-OCSP muss der Browser bei jedem TLS den OCSP-Responder der Zertifizierungsstelle kontaktieren. Bei großem Umfang führt dies zu Latenzzeiten, schafft eine Abhängigkeit von der Infrastruktur Dritter und wirft Datenschutzfragen auf. OCSP-Stapling, definiert in RFC 6066, behebt alle drei Probleme, indem es die Verantwortung für das Abrufen der OCSP-Antwort vom Browser auf den Webserver verlagert.

So funktioniert OCSP-Stapling

Beim OCSP-Stapling ruft der Webserver in regelmäßigen Abständen eine OCSP-Antwort vom Responder der Zertifizierungsstelle ab und speichert sie lokal im Cache. Wenn ein Browser einen TLS initiiert, fügt der Server diese im Cache gespeicherte OCSP-Antwort zusammen mit dem Zertifikat in die TLS ein (oder „heftet“ sie an). Der Browser validiert die digitale Signatur der angehängten Antwort und überprüft deren Zeitstempel zur Aktualität, ohne dabei eine separate Netzwerkanfrage an die Zertifizierungsstelle zu stellen.

Der Vorgang läuft wie folgt ab:

1. Der Webserver sendet eine OCSP-Anfrage an den Responder der Zertifizierungsstelle, in der Regel in regelmäßigen Abständen (beispielsweise alle paar Stunden).
2. Der Responder der Zertifizierungsstelle gibt eine signierte OCSP-Antwort zurück.
3. Der Server speichert die Antwort im Cache.
4. Bei jedem TLS übermittelt der Server dem sich verbindenden Client im Rahmen des Handshakes die zwischengespeicherte Antwort.
5. Der Client überprüft die Signatur und die Zeitstempel der Antwort und stellt anschließend die Verbindung her.

Da der Server die OCSP-Abfrage übernimmt, muss der Browser während der Verbindung niemals direkt bei der Zertifizierungsstelle nach Sperrdaten anfragen.

Vorteile des OCSP-Staplings

OCSP-Stapling bietet gegenüber herkömmlichem OCSP drei wesentliche Vorteile:

• Verbesserte Leistung.
  Der Browser erhält den Sperrstatus des Zertifikats im Rahmen des TLS , wodurch der Hin- und Rückweg zum OCSP-Responder der Zertifizierungsstelle entfällt. Dies verkürzt die Zeit für den Verbindungsaufbau, insbesondere für Nutzer, die geografisch weit von der Infrastruktur der Zertifizierungsstelle entfernt sind.
• Verbesserte Sicherheit.
  Da der Browser keine separate OCSP-Anfrage mehr stellen muss, verringert das Stapling die Angriffsfläche. Zudem wird das Risiko von Fehlalarmen minimiert, die auftreten können, wenn OCSP-Responder nicht erreichbar sind und Clients auf ein „Soft-Fail“-Verhalten zurückgreifen.
• Verbesserter Datenschutz für Benutzer.
  Beim herkömmlichen OCSP erhält die Zertifizierungsstelle für jedes Zertifikat, das der Benutzer überprüft, eine Anfrage, wodurch das Surfverhalten offengelegt wird. Beim „Stapling“ erhält die Zertifizierungsstelle nur Anfragen vom Webserver, nicht von einzelnen Benutzern.

Was ist „OCSP Must-Staple“?

OCSP Must-Staple ist eine in RFC 7633 definierte Zertifikatserweiterung, die Browser anweist, während des TLS eine gültige „stapled“ OCSP-Antwort zu verlangen.Wenn der Server keine „stapled“ Antwort bereitstellt, muss der Browser die Verbindung ablehnen, anstatt ohne Sperrdaten fortzufahren.

Diese Erweiterung schließt eine wichtige Lücke im Standard-OCSP-Modell. Ohne „Must-Staple“ verfolgen die meisten Browser einen „Soft-Fail“-Ansatz: Wenn sie den OCSP-Responder nicht erreichen können (oder wenn der Server keine Antwort „stapelt“), lassen sie die Verbindung dennoch zu. Das bedeutet, dass ein kompromittiertes Zertifikat akzeptiert werden könnte, wenn ein Angreifer den OCSP-Datenverkehr zwischen dem Client und der Zertifizierungsstelle blockiert.

Must-Staple wendet eine „Hard-Fail“-Richtlinie für Zertifikate an, die diese Erweiterung enthalten. Der Nachteil dabei ist, dass Serverbetreiber sicherstellen müssen, dass ihre OCSP-Stapling-Konfiguration zuverlässig ist, da eine fehlende oder abgelaufene Stapling-Antwort dazu führt, dass legitime Verbindungen fehlschlagen.

Vorteile von OCSP gegenüber CRLs

OCSP bietet mehrere betriebliche Vorteile, durch die es sich besonders gut für Umgebungen eignet, in denen zeitnahe Sperrdaten und Ressourceneffizienz eine wichtige Rolle spielen:

• Echtzeitstatus.
  OCSP überprüft den Status eines Zertifikats zum Zeitpunkt der Anfrage und stützt sich nicht auf eine regelmäßig veröffentlichte Liste. Das bedeutet, dass die Informationen zur Sperrung so aktuell sind, wie es die Datenquelle des Antwortgebers zulässt.
• Kleinere Antwortdatenmengen.
  Eine OCSP-Antwort bezieht sich auf ein einzelnes Zertifikat und ist daher deutlich kleiner als eine CRL, in der alle von einer Zertifizierungsstelle ausgestellten widerrufenen Zertifikate aufgeführt sind. Dadurch eignet sich OCSP besonders gut für Geräte mit begrenzten Ressourcen wie Smartphones, IoT und eingebettete Systeme, die nur über begrenzten Speicherplatz und begrenzte Rechenleistung verfügen.
• Geringere Bandbreitenbelastung.
  Da Clients den Status nur für die Zertifikate abfragen, auf die sie stoßen, entfällt durch OCSP die Notwendigkeit, große CRL-Dateien herunterzuladen und zu analysieren. Dies ist besonders in Umgebungen mit Tausenden oder Millionen aktiver Zertifikate von großem Vorteil.
• Eignet sich besser für zeitkritische Anwendungsfälle.
  In Szenarien wie der Netzwerkzugangskontrolle (NAC), in denen Zugriffsentscheidungen sofort getroffen werden müssen, bieten OCSP-Abfragen in Echtzeit eine Reaktionsgeschwindigkeit, mit der CRL-Caching-Intervalle nicht mithalten können.

Einen umfassenden Vergleich zwischen OCSP und CRLs, einschließlich eines Entscheidungsrahmens für den jeweiligen Einsatzzweck, finden Sie unter„CRL vs. OCSP: Was Sie wissen müssen“.

Einschränkungen und zu beachtende Aspekte bei OCSP

Trotz seiner Vorteile bringt OCSP eine Reihe von betrieblichen Herausforderungen mit sich, die Unternehmen kennen sollten, bevor sie es als primären Sperrmechanismus einsetzen.

Datenschutzbedenken

Im Standard-OCSP-Modell sendet der Client für jedes Zertifikat, das er überprüft, die Seriennummer des Zertifikats an den OCSP-Responder der Zertifizierungsstelle. Das bedeutet, dass die Zertifizierungsstelle (oder der Betreiber des Responders) erkennen kann, welche Zertifikate die Nutzer überprüfen, wodurch sich Surfangebote und andere Nutzungsmuster ableiten lassen. OCSP-Stapling wurde speziell entwickelt, um dieses Problem zu mindern, doch nicht auf allen Servern ist Stapling aktiviert.

Verfügbarkeitsabhängigkeit

OCSP führt eine Echtzeitabhängigkeit von der Verfügbarkeit des OCSP-Responders ein. Fällt der OCSP-Responder aus, müssen Clients entscheiden, wie sie vorgehen sollen. Die meisten Browser und Anwendungen verfolgen einen „Soft-Fail“-Ansatz, d. h., sie lassen die Verbindung auch dann zu, wenn sie den Sperrstatus des Zertifikats nicht überprüfen können. Dieses Verhalten macht OCSP bei Ausfällen praktisch optional, was den Sicherheitsnutzen der Sperrprüfung untergräbt.

Die Alternative, „Hard-Fail“, blockiert alle Verbindungen, wenn der OCSP-Responder nicht erreichbar ist. Dies ist zwar sicherer, birgt jedoch Risiken für die Verfügbarkeit, da ein Ausfall des Responders dazu führen könnte, dass alle Dienste ausfallen, die zur Validierung auf ihn angewiesen sind.

Leistung im großen Maßstab

Jede OCSP-Prüfung erfordert einen Hin- und Rückweg über das Netzwerk zum Responder. Bei Diensten mit hohem Datenverkehr oder Clients, die viele Zertifikate in schneller Folge validieren, können diese Abfragen zu einer messbaren Latenz führen. Zwar entfällt durch OCSP-Stapling der Hin- und Rückweg zwischen Browser und Zertifizierungsstelle, doch muss der Server weiterhin den Responder abfragen, um seine zwischengespeicherten Antworten zu aktualisieren.

Einzige Schwachstelle

Wenn eine Organisation einen einzelnen OCSP-Responder (oder einen kleinen Cluster ohne geografische Redundanz) betreibt, wird dieser Responder zu einer kritischen Abhängigkeit für jedes Zertifikat, das er bereitstellt. Die Responder-Infrastruktur muss auf hohe Verfügbarkeit ausgelegt sein und über redundante Knoten, Lastenausgleich sowie Überwachungsmechanismen verfügen, um Ausfälle zu erkennen und darauf zu reagieren, bevor sie die Zertifikatsvalidierung beeinträchtigen.

Wie Browser OCSP derzeit handhaben

Die Art und Weise, wie Browser mit OCSP umgehen, hat sich erheblich weiterentwickelt, und das Verständnis des aktuellen Verhaltens der Browser ist für jede Organisation, die eine PKI-Infrastruktur verwaltet, von großer Bedeutung.

Google Chromeführt für die meisten öffentlich vertrauenswürdigen Zertifikate keine herkömmlichen OCSP-Prüfungen durch. Stattdessen verwaltet Google CRLSets, eine kuratierte und komprimierte Sammlung von Seriennummern widerrufener Zertifikate, die über Browser-Updates an Chrome verteilt wird. Dieser Ansatz vermeidet die Latenzzeiten und Datenschutzbedenken, die mit Live-OCSP-Abfragen verbunden sind, allerdings beschränkt sich die Abdeckung durch CRLSets auf Widerrufe mit hoher Priorität und umfasst nicht jedes widerrufene Zertifikat.

Mozilla Firefoxunterstützt OCSP nur noch als Ausweichlösung, da sich die primäre Strategie des Unternehmens auf die lokale Zertifikatsvalidierung verlagert hat. Der Browser nutzt CRLite, eine Technologie, die den gesamten aus CRLs abgeleiteten Satz an Sperrdaten in eine kompakte Datenstruktur komprimiert, die an Browser verteilt werden kann. Dank CRLite kann Firefox lokale Sperrprüfungen durchführen, ohne einen OCSP-Responder anzufragen.

Apple Safariführt im Rahmen seines Zertifikatsvalidierungsprozesses OCSP-Prüfungen durch. Apple hat sich in der Vergangenheit stärker auf OCSP verlassen als Chrome oder Firefox, nutzt jedoch auch lokales Caching und Batch-Prüfungen, um die Auswirkungen von Live-Abfragen auf die Leistung und den Datenschutz zu verringern.

Der allgemeine Branchentrend ist eindeutig: Im öffentlichen Web verlagern sich die Browser zunehmend von Live-OCSP-Abfragen hin zu lokal verteilten Sperrdaten. OCSP bleibt jedoch der Standard-Validierungsmechanismus in Unternehmens-PKI, privaten Vertrauenshierarchien und speziellen Umgebungen, in denen das Verhalten von Browsern keine Rolle spielt.

Wird OCSP ausgemustert?

Kurz gesagt: Nein. Allerdings gibt es Bestrebungen, OCSP aus der öffentlichen Web-PKI auslaufen zu lassen. Große Browser-Anbieter sind zu dem Schluss gekommen, dass OCSP keinen zuverlässigen Schutz bietet, da die meisten Implementierungen ein „Soft-Fail“-Modell verwenden: Wenn der OCSP-Responder nicht erreichbar ist, setzt der Browser die Verbindung trotzdem fort. OCSP verursacht zudem Latenzzeiten, wirft Datenschutzbedenken auf (da die Seriennummer des Zertifikats dem Responder offengelegt wird) und erhöht den Betriebsaufwand.

Infolgedessen entwickeln sich die Browser-Ökosysteme in Richtung alternativer Sperrmechanismen. Chrome setzt bereits seit Langem auf vom Browser verwaltete Sperrdaten anstelle von Live-OCSP-Abfragen, während Firefox CRLite eingeführt hat. Diese Entwicklung wird durch die Verkürzung der Gültigkeitsdauer von Zertifikaten – einschließlich der Umstellung auf47-Tage-Zertifikate – sowie durch die Entscheidung großer Zertifizierungsstellen, die OCSP-Unterstützung einzustellen, weiter beschleunigt.

OCSP verschwindet jedoch nicht vollständig aus der PKI. Es wird weiterhin in großem Umfang in Unternehmens-PKIs, behördlichen Infrastrukturen, VPN-Authentifizierungssystemen, Ökosystemen zur Codesignierung und anderen verwalteten Umgebungen eingesetzt, in denen Clients und Responder zentral gesteuert werden. In diesen Umgebungen liefert OCSP weiterhin zeitnahe Informationen zu Sperrungen und unterstützt Validierungsanforderungen, die von browserorientierten Alternativen nicht abgedeckt werden.

Für Organisationen, die eine eigene PKI betreiben, lautet die praktische Erkenntnis: OCSP entwickelt sich weiter, es verschwindet nicht. Ihre OCSP-Infrastruktur wird auch weiterhin eine entscheidende Rolle in unternehmensinternen und privaten PKI-Umgebungen spielen, selbst wenn öffentliche Webbrowser auf andere Mechanismen zurückgreifen.

OCSP-Überwachung und Verfügbarkeit

Für Unternehmen, die zur Zertifikatsvalidierung auf OCSP setzen, ist die Überwachung der Verfügbarkeit des OCSP-Responders unverzichtbar. Ein nicht reagierender OCSP-Responder kann in Ihrer gesamten Umgebung Kettenreaktionen auslösen – von fehlgeschlagenen TLS über blockierten VPN-Zugang bis hin zu ins Stocken geratenen Anwendungsabläufen.

Die Folgen eines Ausfalls des OCSP-Responders hängen davon ab, wie Ihre Clients konfiguriert sind. In einer „Soft-Fail“-Umgebung bleibt ein Ausfall möglicherweise unbemerkt, da die Clients die Überprüfung auf widerrufene Zertifikate stillschweigend überspringen. Dadurch entsteht eine Sicherheitslücke, durch die widerrufene Zertifikate akzeptiert werden könnten. In einer „Hard-Fail“-Umgebung (oder wenn „OCSP Must-Staple“ verwendet wird) führt ein Ausfall des Responders direkt zu Verbindungsfehlern.

Beide Szenarien sind problematisch. Im ersten Fall geht die Sicherheitsgarantie verloren, die die Überprüfung auf widerrufene Zertifikate bietet. Im zweiten Fall kommt es zu Verfügbarkeitsbeeinträchtigungen, die sich auf Ihre gesamte Infrastruktur auswirken können.

Eine proaktive OCSP-Überwachung beugt beiden Risiken vor. Indem Sie kontinuierlich prüfen, ob Ihre OCSP-Endpunkte erreichbar sind, können Sie Ausfälle erkennen, bevor sie sich auf die Benutzer auswirken, und automatische Warnmeldungen an Ihr Betriebsteam auslösen. Toolszur Automatisierung des Zertifikatslebenszyklusbieten diese Funktion als Teil eines umfassenderen Ansatzes zur Verwaltung der Zertifikatsinfrastruktur und verschaffen Ihrem Team neben Informationen zum Ablauf, zur Ausstellung und zur Erneuerung von Zertifikaten auch Einblick in den Zustand des OCSP.

Wie Keyfactor bei OCSP Keyfactor

Die Verwaltung einer OCSP-Infrastruktur in großem Maßstab erfordert mehr als nur die Einrichtung eines Responders. Sie erfordert Transparenz, Automatisierung und eine PKI-Plattform, die die Sperrung von Zertifikaten als vorrangiges betriebliches Anliegen behandelt.

EJBCA, die PKI-Plattform Keyfactor, enthält eine integrierte Validierungsstelle (Validation Authority, VA), die sowohl OCSP-Responder als auch die Veröffentlichung von CRLs unterstützt. Der OCSP-Responder EJBCAunterstützt CA-integrierte und delegierte Signaturmodelle, Multi-CA-Bereitstellungen sowie Hochverfügbarkeitsarchitekturen mit mehreren Responder-Knoten.

Keyfactor Command bietet im Rahmen seiner Plattform zur Automatisierung des Zertifikatslebenszyklus eine kontinuierliche Überwachung und Benachrichtigung zu OCSP-Endpunkten. Ihr Team kann die Verfügbarkeit von OCSP-Respondern in Echtzeit verfolgen, Benachrichtigungen erhalten, wenn Endpunkte nicht mehr reagieren, und den Zustand der Responder mit dem Gesamtzustand Ihrer Zertifikatsumgebung in Zusammenhang bringen.

PKI as a Service bietet eine vollständig verwaltete PKI, die eine OCSP-Responder-Infrastruktur umfasst, sodass Unternehmen den betrieblichen Aufwand für den Betrieb und die Überwachung ihrer eigenen Sperrinfrastruktur auslagern können.