OCSP für Enterprise-PKI verstehen und optimieren

Einführung

A Widerruf des Zertifikats Ein System ist nur so stark wie die Infrastruktur, die es durchsetzt. Wenn ein privater Schlüssel kompromittiert oder ein Zertifikat fälschlicherweise ausgestellt wurde, ist der Widerruf eine entscheidende Verteidigungslinie. Dieser Mechanismus signalisiert allen vertrauenden Parteien in Ihrer Umgebung, dem Zertifikat nicht mehr zu vertrauen. Bescheinigung sofort. Der Widerruf funktioniert jedoch nur, wenn Kunden den Widerrufsdienst tatsächlich erreichen, eine aktuelle Antwort erhalten und entsprechend reagieren können.

Das Online Certificate Status Protocol (OCSP) ist der Echtzeit-Überprüfungsmechanismus für Zertifikatssperrungen und das Herzstück moderner PKI. Trotz seiner zentralen Rolle gehört OCSP jedoch nach wie vor zu den am uneinheitlichsten implementierten und am wenigsten verstandenen Komponenten der Zertifikatsinfrastruktur von Unternehmen. Organisationen installieren die Online-Responder-Rolle, setzen einige Häkchen und gehen davon aus, dass alles erledigt ist. Monate später stellen sie fest, dass ihr OCSP-Responder unbemerkt Fehler zurückgegeben hat, ihr Signaturzertifikat abgelaufen ist, ohne dass es jemand bemerkt hat, oder dass ihre Server OCSP-Antworten nie an TLS-Handshakes angehängt haben.

Dieser Leitfaden behandelt die OCSP-Konfiguration von Anfang bis Ende: Was OCSP ist, wie es auf Protokollebene funktioniert, wie man es auf den Plattformen konfiguriert, die in Ihrem Unternehmen eingesetzt werden, und welche erweiterten Einstellungen eine produktionsreife Bereitstellung von einer einfachen Installation unterscheiden.

Was ist OCSP und warum ist es wichtig?

Das in RFC 6960 definierte Online Certificate Status Protocol (OCSP) bietet Clients einen Mechanismus, um den Widerrufsstatus eines bestimmten Zertifikats in Echtzeit abzufragen. Im Gegensatz dazu Zertifikatssperrlisten (CRLs)), die erfordern, dass ein Client eine gesamte Liste signierter Zertifikate herunterlädt und diese lokal analysiert, ermöglicht OCSP eine gezielte Abfrage: „Wurde das Zertifikat mit der Seriennummer X, ausgestellt von CA Y, widerrufen?“

Der OCSP-Responder, der entweder von der Zertifizierungsstelle selbst betrieben oder an einen separaten Server delegiert wird, gibt eine von drei Antworten zurück:

• GutDieser Status bedeutet, dass das Zertifikat als gültig und aktuell nicht widerrufen gilt. Er bedeutet zumindest, dass die Seriennummer nicht in der vom Antwortanbieter verwendeten Sperrliste (CRL) gefunden wurde. Er bestätigt jedoch nicht, dass das Zertifikat jemals ausgestellt wurde. Ohne eine deterministische Antwortkonfiguration (KB 2960124) kann zudem selbst eine nicht existierende oder gefälschte Seriennummer den Status „Gut“ zurückgeben.
• WiderrufenDieser Status signalisiert, dass das Zertifikat aufgrund eines Widerrufs ungültig ist und wird von Clients üblicherweise als schwerwiegender Fehler behandelt. Der Widerruf kann vorübergehend (z. B. bei „certificateHold“) oder dauerhaft sein. In manchen Fällen erlaubt RFC 6960 diesen Status auch für Zertifikatsseriennummern, die von der Zertifizierungsstelle nie ausgestellt wurden. In solchen Fällen soll sichergestellt werden, dass der Client das Zertifikat ablehnt, anstatt weitere Statusinformationen wie eine Sperrliste (CRL) abzufragen. Dieses Verhalten ist optional und wird in bestimmten Implementierungen verwendet. Aus Gründen der Abwärtskompatibilität mit RFC 2560 können Antwortserver alternativ „unbekannt“ für nicht ausgestellte Seriennummern zurückgeben. Wird „widerrufen“ für nicht ausgestellte Zertifikate verwendet, erfordert RFC 6960 die Einbindung der erweiterten Definition für widerrufene Zertifikate sowie bestimmter standardisierter Antwortfelder.
• UnbekanntDer Responder kann den Status des Zertifikats nicht ermitteln, entweder weil die Seriennummer nicht erkannt wird oder weil das Zertifikat nicht von der Zertifizierungsstelle ausgestellt wurde, für die dieser Responder konfiguriert ist.

Die Antwort „Unbekannt“ ist einer der am meisten missverstandenen Zustände in OCSP. Sie ist nicht gleichbedeutend mit WiderrufenEs bedeutet vielmehr, dass der Antwortende den Status des Zertifikats nicht ermitteln kann. Das Verhalten der Clients variiert: Viele Implementierungen behandeln Unbekannt oder OCSP-Fehler als Soft-Fail behandeln und die Verbindung aufrechterhalten, während andere so konfiguriert werden können, dass Hard-Fail-Richtlinien durchgesetzt werden.

Diese Variabilität kann in Umgebungen, die auf strikte Widerrufsprüfung angewiesen sind, ein Risiko darstellen. Ist die OCSP-Infrastruktur nicht verfügbar, falsch konfiguriert oder liefert sie veraltete Antworten, kann der Widerruf möglicherweise nicht zuverlässig durchgesetzt werden. In solchen Fällen werden die durch eine PKI gewährleisteten Sicherheiten geschwächt, und es besteht die Gefahr, Zertifikaten zu vertrauen, die nicht mehr gültig sein sollten, einschließlich solcher, die mit kompromittierten Schlüsseln verknüpft sind.

So funktioniert OCSP: Der vollständige Anfrage-Antwort-Lebenszyklus

Das Verständnis von OCSP auf Protokollebene ist für eine effektive Konfiguration und sinnvolle Fehlersuche unerlässlich.

Schritt 1: Zertifikatsübergabe

Während eines TLS-Handshakes präsentiert der Server dem Client sein Zertifikat. Das Zertifikat enthält ein Zugriff auf Behördeninformationen (AIA) Die Erweiterung gibt die URL des OCSP-Responders an, beispielsweise http://ocsp.example.com. Wenn OCSP-Stapling aktiviert ist, fügt der Server eine vorab abgerufene und zwischengespeicherte OCSP-Antwort direkt in den Handshake ein, sodass der Client den Responder nicht mehr kontaktieren muss.

Schritt 2: Erstellung der OCSP-Anfrage

Der Client erstellt eine OCSP-Anfrage, die den Namens-Hash des Ausstellers, den Hash des öffentlichen Schlüssels des Ausstellers und die Seriennummer des zu validierenden Zertifikats enthält. Diese Felder sind in der CertID-Struktur von RFC 6960 definiert und werden mithilfe eines Digest-Algorithmus gehasht.

Schritt 3: Übertragung anfordern

Die OCSP-Anfrage wird über HTTP an die im AIA-Extension des Zertifikats hinterlegte Responder-URL gesendet. OCSP verwendet üblicherweise HTTP (Port 80) für optimale Performance und Cache-Fähigkeit. RFC 6960 definiert das Anfrageformat, während RFC 5019 ein schlankes Profil für Umgebungen mit hohem Anfrageaufkommen bereitstellt.

Schritt 4: Bewertung der Einsatzkräfte

Der OCSP-Responder empfängt die Anfrage und ermittelt den Sperrstatus des Zertifikats. Die Vorgehensweise beim Abrufen dieser Daten ist implementierungsabhängig. In Microsoft Windows ADCS-Umgebungen lädt der Online-Responder CRLs von der Zertifizierungsstelle herunter und verwendet diese zur Bestimmung des Sperrstatus. In anderen Implementierungen, wie z. B. Keyfactor EJBCA, kann der Responder die Datenbank der Zertifizierungsstelle direkt abfragen oder vorab generierte, zwischengespeicherte Antworten bereitstellen.

Schritt 5: Unterzeichnete Antwort

Der Antwortende sendet eine digital signierte Antwort zurück. Gemäß RFC 6960 muss der OCSP-Signaturschlüssel einer der drei folgenden autorisierten Parteien gehören: einer Zertifizierungsstelle (CA), die das zu prüfende Zertifikat ausgestellt hat, einem vertrauenswürdigen Antwortenden, dessen öffentlicher Schlüssel vom Client als vertrauenswürdig eingestuft wird, oder einem von der CA benannten Antwortenden mit einem speziell gekennzeichneten Delegationszertifikat dieser CA. Die Signatur gewährleistet, dass die Antwort während der Übertragung nicht manipuliert werden kann. Bevor der Client einer OCSP-Antwort vertraut, muss er die Signatur validieren, die Zertifikatskette der Signatur überprüfen und die Autorisierung des Antwortenden bestätigen.

Schritt 6: Kundenvalidierung

Der Client überprüft die Signatur der OCSP-Antwort, prüft die Gültigkeitszeitstempel, um sicherzustellen, dass die Antwort aktuell ist, und entscheidet anhand des zurückgegebenen Status, ob die Verbindung fortgesetzt oder beendet wird. RFC 6960 Abschnitt 2.4 definiert vier Felder, die die Gültigkeit der Antwort regeln:

• diesesUpdate – Der letzte Zeitpunkt, zu dem der angegebene Status nach Kenntnis des Antwortenden korrekt war.
• nächstesUpdate – Der Zeitpunkt, zu dem oder vor dem neuere Informationen über den Status des Zertifikats verfügbar sein werden.
• produziert bei – Der Zeitpunkt, zu dem der OCSP-Antwortende diese Antwort unterzeichnet hat.
• Widerrufszeit – Der Zeitpunkt, zu dem das Zertifikat widerrufen oder vorläufig ausgesetzt wurde. Nur bei Widerrufsmeldungen vorhanden.

Das Feld „nextUpdate“ hat direkte Auswirkungen auf den Betrieb. Wenn ein Responder seine Sperrdaten nicht vor Ablauf von „nextUpdate“ aktualisiert, behandeln Clients die Antwort als veraltet. Je nach Konfiguration greifen sie entweder auf die CRL-basierte Prüfung zurück oder lehnen die Verbindung in kritischen Umgebungen vollständig ab. Unter Windows ADCS setzt der Online Responder das Feld „nextUpdate“ in seinen Antworten automatisch auf das Ablaufdatum der verwendeten CRL. Es gibt keine native Konfigurationsoption, um dies zu überschreiben. Die einzige Möglichkeit, die Cache-Fenster für clientseitige OCSP-Antworten in ADCS zu verkürzen, besteht darin, die Gültigkeitsdauer der CRL auf der ausstellenden Zertifizierungsstelle zu reduzieren.

OCSP-Stapling: Das Leistungs- und Datenschutz-Upgrade

Das traditionelle OCSP weist zwei wesentliche operative Probleme auf. Erstens erhöht es die Latenz jedes TLS-Handshakes, da der Client vor dem Verbindungsaufbau eine separate HTTP-Anfrage an den OCSP-Responder senden muss. Zweitens birgt es ein Datenschutzrisiko, da der OCSP-Responder Client-IP-Adressen mit Zertifikatsabfragen korrelieren kann, was in regulierten Umgebungen Bedenken hinsichtlich der Einhaltung von Vorschriften wie HIPAA und DSGVO aufwirft.

OCSP-Stapling behebt beide Probleme, indem es die Verantwortung für die Überprüfung des Zertifikatssperrstatus vom Client auf den Server verlagert. Es wird über die in Abschnitt 8 von RFC 6066 definierte TLS-Zertifikatstatusanforderungserweiterung (status_request) implementiert.

Mit OCSP-Heftklammerung:

1. Der Server fragt regelmäßig den OCSP-Responder der Zertifizierungsstelle nach dem Widerrufsstatus seines eigenen Zertifikats ab.
2. Die signierte und mit einem Zeitstempel versehene OCSP-Antwort wird vom Server zwischengespeichert.
3. Bei jedem TLS-Handshake übermittelt der Server diese zwischengespeicherte Antwort zusammen mit seinem Zertifikat.
4. Der Client erhält sowohl das Zertifikat als auch dessen Widerrufsstatus in einem einzigen Roundtrip, ohne dass eine separate Verbindung zur Zertifizierungsstelle erforderlich ist.

Da die OCSP-Antwort vom OCSP-Responder der Zertifizierungsstelle digital signiert wird, kann ein bösartiger Server sie weder fälschen noch verändern. Der Client überprüft die Signatur der angehängten Antwort weiterhin, bevor er ihr vertraut. Dadurch bleibt die Sicherheit erhalten, während gleichzeitig der zusätzliche Roundtrip und das Risiko eines Datenlecks vermieden werden.

Für einen detaillierteren Einblick in die OCSP-Stapling-Konfiguration, die Auswirkungen auf die Leistung und die Veränderungen des OCSP-Abfragevolumens durch kürzere Zertifikatslebensdauern lesen Sie unsere entsprechenden Artikel zu diesem Thema. Einführung in OCSP-Stapling und OCSP-Heftung und Gültigkeitsdauer von Zertifikaten.

Konfigurieren des Windows Online Responders: Erweiterte Einstellungen

Die Bereitstellung der Windows Online Responder-Rolle ist relativ unkompliziert, aber die korrekte Konfiguration für eine produktive PKI-Umgebung erfordert ein tieferes Verständnis dafür, wie ADCS Sperrdaten, Responder-Autorisierung, Signaturzertifikate und Antwortvalidierung handhabt.

Viele der Standardeinstellungen sind eher auf grundlegende Funktionalität als auf umfassende Sicherheitsgarantie oder den Betrieb in großen Unternehmen ausgelegt. Daher entdecken Organisationen Sicherheitslücken oft erst, wenn Interoperabilitätsprobleme, veraltete Antworten, Vertrauensbrüche oder unerwartetes Validierungsverhalten auftreten. Die folgenden Abschnitte behandeln verschiedene fortgeschrittene OCSP-Konfigurationsbereiche in Windows ADCS, die erhebliche Auswirkungen auf Betrieb und Sicherheit in realen Umgebungen haben.

Deterministische GOOD-Antworten und Hotfix 2960124

Ein häufig übersehenes Verhalten in ADCS-Umgebungen ist die standardmäßige Bewertung des Zertifikatsstatus durch den Windows Online Responder. Dieser stützt sich primär auf CRL-Daten, um den Sperrstatus zu ermitteln. Fehlt die Seriennummer eines Zertifikats in der CRL, kann der Responder daher annehmen, das Zertifikat sei gültig und den Status „GUT“ zurückgeben, selbst wenn dieses Zertifikat nie von der Zertifizierungsstelle ausgestellt wurde.

In der Praxis bedeutet dies, dass ein gefälschtes Zertifikat mit einer erfundenen Seriennummer die OCSP-Validierung bestehen könnte. CRL Die Datenbank erfasst lediglich widerrufene Zertifikate; sie enthält keine Informationen über rechtmäßig ausgestellte. Daher kann der Sachbearbeiter, der ausschließlich auf die CRL zurückgreift, ein echtes Zertifikat nicht von einem gefälschten mit einer erfundenen Seriennummer unterscheiden.

Microsoft hat dieses Problem mit dem Hotfix KB 2960124 behoben. Wenn diese Funktion aktiviert ist, kann der Online-Responder so konfiguriert werden, dass er eine Referenzliste aller von der Zertifizierungsstelle ausgegebenen Seriennummern führt. Mit dieser Liste gibt der Responder die erforderlichen Informationen zurück. UNKNOWN statt GUT für jede Seriennummer, die nicht erkannt wird. Dies ist eine sinnvolle Sicherheitsverbesserung, die das Verhalten mit den Vorgaben von RFC 6960 in Einklang bringt.

Die Aktivierung dieser Funktion erfordert die folgenden Schritte, die in der vorgegebenen Reihenfolge ausgeführt werden müssen. Unter Windows Server 2016 und höher sind nur die Schritte 1 und 2 erforderlich, da der Hotfix bereits integriert ist. Unter Server 2008 R2 und 2012 R2 sind alle drei Schritte erforderlich.

Der im KB-Artikel 2960124 beschriebene Exportprozess für Seriennummern auf CA-Seite ist weiterhin auf der ausstellenden Zertifizierungsstelle (CA) erforderlich. Dieser Prozess extrahiert die Seriennummern ausgestellter Zertifikate aus der CA-Datenbank und veröffentlicht sie in der OCSP-Umgebung. Ohne diesen kontinuierlich aktualisierten Datensatz verfügt der Responder über keine Referenzliste und kann legitime Seriennummern nicht von gefälschten unterscheiden. Das deterministische Verhalten, bei dem für unbekannte Seriennummern „UNKNOWN“ statt „GOOD“ zurückgegeben wird, funktioniert ohne diesen Datensatz nicht.

Wenn Sie mehrere Online-Responder betreiben, sollten diese in einem OCSP-Array organisiert werden. Ein Array ist eine logische Gruppierung von Online-Respondern mit derselben Widerrufskonfiguration. Ein Responder wird als Array-Controller festgelegt, dessen Konfiguration die maßgebliche Quelle darstellt. Alle anderen Mitglieder synchronisieren ihre Einstellungen mit diesem Controller. In dieser Konfiguration muss das Verzeichnis der Seriennummern auf einer Netzwerkfreigabe abgelegt werden, auf die alle Mitglieder Zugriff haben, anstatt lokal auf einem einzelnen Server gespeichert zu sein.

Schritt 1: Erstellen Sie das Verzeichnis für Seriennummern

Erstellen Sie auf dem CA-Server ein Verzeichnis, in dem leere Dateien mit den jeweiligen Seriennummern der ausgestellten Zertifikate gespeichert werden. Wenn Sie ein OCSP-Array mit mehreren Online-Respondern betreiben, platzieren Sie dieses Verzeichnis auf einer Netzwerkfreigabe, damit alle Array-Mitglieder mit Leseberechtigung darauf zugreifen können. Bei lokaler Speicherung stellen Sie sicher, dass das OCSP-Dienstkonto Lesezugriff auf das Verzeichnis hat.

Speichern Sie das folgende Skript als Certs.ps1 auf dem CA-Server:

param( [ValidateScript({Test-Path $_})] [String] $Path ) pushd $Path dir | foreach { remove-item $_ -force } certutil.exe -out serialnumber -restrict "Disposition = 20" -view | foreach { if($_ -match 'Seriennummer: "([^"]+)"') { New-Item -type File $matches[1] | out-null } } Popd

Führen Sie das Skript mit dem Verzeichnispfad als Parameter aus:

.\Certs.ps1 -Path "C:\OCSPSerials"

Planen Sie die regelmäßige Ausführung dieses Skripts. Ein vierstündiger Rhythmus ist ein guter Anfang; passen Sie ihn an Ihre Bedürfnisse an. CRL Veröffentlichungshäufigkeit. Wird das Skript zu selten ausgeführt, erhält ein nach der letzten Ausführung ausgestelltes Zertifikat vom OCSP-Responder bis zur nächsten Ausführung den Status UNKNOWN, was zu Validierungsfehlern für kürzlich registrierte Zertifikate führt.

Schritt 2: Konfigurieren Sie die Registry auf dem OCSP-Server

Öffnen Sie den Registrierungseditor und navigieren Sie zu:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OcspSvc\Responder

Erweitern Sie den Schlüssel, klicken Sie auf den Knoten, der der Widerrufskonfiguration Ihrer Zertifizierungsstelle entspricht, und klicken Sie dann mit der rechten Maustaste auf „Anbieter“. Wählen Sie „Neu“ > „Mehrere Zeichenfolgenwerte“, benennen Sie den Wert „IssuedSerialNumbersDirectories“ und geben Sie als Wert den Pfad des in Schritt 1 erstellten Verzeichnisses an. Verwenden Sie für Netzwerkfreigaben das UNC-Format: \\Servername\Freigabename.

Starten Sie den OCSP-Dienst neu, nachdem Sie die Änderung in der Registrierung gespeichert haben.

Schritt 3: Installieren Sie den Hotfix

Installieren Sie den Hotfix jetzt unter Windows Server 2008 R2 oder 2012 R2. Der Hotfix ist in Server 2016 und höher bereits integriert, die Schritte 1 und 2 (Einrichtung des Seriennummernverzeichnisses und Konfiguration der Registrierung) sind jedoch weiterhin in allen Versionen erforderlich.

Nach der Konfiguration liefert jede OCSP-Anfrage für eine Seriennummer außerhalb des Referenzverzeichnisses den Status UNKNOWN anstatt GOOD. Sie können dies überprüfen, indem Sie die OCSP-Überwachung aktivieren und die Ereignis-ID 5125 prüfen. Eine unbekannte Seriennummer wird mit dem Status UNKNOWN protokolliert, während dieselbe Anfrage ohne diese Konfiguration GOOD zurückgegeben hätte.

Verwaltung von Widerrufen mit der lokalen CRL

Es gibt eine weniger bekannte Funktion des Windows Online Responders, die in bestimmten Szenarien wirklich wichtig wird: wenn Ihr CA-Datenbank Es gibt keine Aufzeichnungen darüber, ob ein Zertifikat rechtmäßig ausgestellt wurde oder ob eine Seriennummer als widerrufen markiert werden muss, die die Zertifizierungsstelle selbst nie erfasst hat.

Der Online-Responder verwaltet eine eigene interne lokale Sperrliste (Local CRL), eine Liste von Seriennummern, die er unabhängig von der von Ihrer Zertifizierungsstelle (CA) veröffentlichten Sperrliste als widerrufen behandelt. Es handelt sich nicht um eine signierte Sperrliste und es ist kein Zugriff auf den privaten Schlüssel der CA erforderlich. Genau das macht ihn in Situationen nützlich, in denen die CA selbst nicht handeln kann. Fragt ein Client den OCSP-Responder nach einer Seriennummer, die in der lokalen Sperrliste enthalten ist, gibt der Responder „WIDERRUFEN“ zurück, unabhängig davon, was die von der CA ausgestellte Sperrliste besagt.

Wenn Ihre Zertifizierungsstelle ausgefallen ist und aus einer Sicherung wiederhergestellt wurde, sind alle zwischen der letzten Sicherung und dem Ausfall ausgestellten Zertifikate nicht in der wiederhergestellten Datenbank vorhanden. Sie können Zertifikate, deren Ausstellung der Zertifizierungsstelle nicht bekannt ist, nicht widerrufen. Wenn Sie jedoch die Seriennummern dieser Zertifikate aus Protokollen, Registrierungsdatensätzen oder einer anderen Quelle kennen, können Sie sie der lokalen Sperrliste (CRL) hinzufügen. Der OCSP-Responder antwortet dann umgehend mit „WIDERRUFEN“. Dies ist auch der Mechanismus zur Behandlung von Zertifikaten, die zwischen der letzten Sicherung und dem Ausfall ausgestellt wurden. Schelm oder gefälschte Zertifikate, bei denen Sie die Seriennummer kennen, die aber nie von der Zertifizierungsstelle ausgestellt wurden.

Verwenden Sie die lokale Sperrliste (CRL) gezielt und löschen Sie Einträge, sobald die von der Zertifizierungsstelle ausgestellte CRL den korrekten Sperrstatus widerspiegelt. Bei Array-Bereitstellungen müssen Änderungen an der lokalen CRL auf dem Array-Controller vorgenommen werden. Änderungen an einem Mitgliedsknoten werden bei der nächsten Synchronisierung mit dem Controller überschrieben.

Anforderungen an das OCSP-Signaturzertifikat gemäß RFC 6960

Das Signaturzertifikat ist entscheidend für die Vertrauenswürdigkeit von OCSP-Antworten. Clients akzeptieren den Widerrufsstatus nicht einfach. Sie überprüfen die Signatur der Antwort, validieren die Zertifikatskette und bestätigen, dass der Unterzeichner berechtigt ist, im Namen der Zertifizierungsstelle (CA) zu sprechen, die das geprüfte Zertifikat ausgestellt hat. Schlägt einer dieser Schritte fehl, wird die Antwort abgelehnt.

Wer kann Antworten unterzeichnen?

Gemäß RFC 6960 kann eine OCSP-Antwort von einer von drei Instanzen signiert werden: der Zertifizierungsstelle (CA), die das zu prüfende Zertifikat ausgestellt hat, einem Trusted Responder, dessen öffentlicher Schlüssel vom Client direkt als vertrauenswürdig eingestuft wird, oder einem CA Designated Responder – einem delegierten Responder mit einem speziell gekennzeichneten, direkt von der CA ausgestellten Zertifikat. Clients vertrauen OCSP-Antworten nicht blind; sie validieren die Antwortsignatur, erstellen und verifizieren die Zertifikatskette des Signierers und bestätigen, dass dieser berechtigt ist, Informationen zum Widerrufsstatus des abgefragten Zertifikats bereitzustellen.

In Microsoft ADCS-Umgebungen ist das Modell des delegierten Responders die Standardimplementierung. Der Online Responder verwendet ein dediziertes OCSP-Antwortsignaturzertifikat mit der erweiterten Schlüsselverwendung (EKU) „id-kp-OCSPSigning“. Dieses Zertifikat wird üblicherweise von derselben ausstellenden Zertifizierungsstelle (CA) ausgestellt, die auch das zu validierende Zertifikat ausgestellt hat. Beispielsweise sollten Zertifikate, die von der ausstellenden CA1 ausgestellt wurden, mithilfe von OCSP-Antworten validiert werden, die mit einem ebenfalls von der ausstellenden CA1 ausgestellten OCSP-Signaturzertifikat signiert sind, und nicht mit einem Zertifikat der Stammzertifizierungsstelle oder einer anderen ausstellenden CA.

Abschnitt 4.2.2.2 von RFC 6960 verschärfte die Anforderungen an die Autorisierung von Antwortanbietern im Vergleich zu RFC 2560. Wie im RFC festgelegt, müssen Systeme, die auf OCSP-Antworten angewiesen sind, ein Delegierungszertifikat nur dann als von der Zertifizierungsstelle ausgestellt anerkennen, die das betreffende Zertifikat ausgestellt hat, wenn das Delegierungszertifikat und das auf Widerruf geprüfte Zertifikat mit demselben Schlüssel signiert wurden. Ist diese Bedingung nicht erfüllt, müssen Clients den Antwortanbieter nicht als autorisiert anerkennen.

Obwohl RFC 6960 die Abwärtskompatibilität wahrt und alternative ausstellende Schlüssel für ein OCSP-Signaturzertifikat nicht verbietet, wird von solchen Konfigurationen dringend abgeraten, da sie von strikt RFC-6960-konformen Clients möglicherweise nicht akzeptiert werden. In der Praxis bedeutet dies, dass die Verwendung eines von einer Stammzertifizierungsstelle ausgestellten OCSP-Signaturzertifikats zum Signieren von Antworten für von einer ausstellenden Zertifizierungsstelle ausgestellte Zertifikate zu Interoperabilitäts- oder Validierungsfehlern führen kann, insbesondere bei Clients von Drittanbietern oder Nicht-Microsoft-Clients. Jedes Schlüsselpaar einer ausstellenden Zertifizierungsstelle sollte daher über ein eigenes, dediziertes OCSP-Signaturzertifikat verfügen.

CA-Verlängerung und OCSP-Signaturzertifikat-Kontinuität

Eine damit zusammenhängende Frage, die in Umgebungen mit mehreren Zertifizierungsstellen häufig auftaucht, ist, was mit dem OCSP-Vertrauen geschieht, wenn eine Zertifizierungsstelle mit einem neuen Schlüsselpaar erneuert wird. Die Besorgnis ist verständlich. Wenn RFC 6960 vorschreibt, dass das Delegierungszertifikat mit demselben Schlüssel signiert sein muss wie das zu prüfende Zertifikat, … CA-Verlängerung Bestehende OCSP-Responder-Konfigurationen unterbrechen?

In der Praxis lautet die Antwort für Windows-Umgebungen: Nein. RFC 6960 Abschnitt 4.2.2.2 gewährleistet die Abwärtskompatibilität mit RFC 2560 und verbietet nicht die Verwendung eines Responder-Zertifikats, das mit einem anderen CA-Schlüsselpaar ausgestellt wurde. Der RFC weist jedoch darauf hin, dass von einer solchen Vorgehensweise dringend abgeraten wird, da Clients einen Responder mit einem solchen Zertifikat nicht als autorisierten Responder erkennen müssen. Windows implementiert dies korrekt, sodass eine mit einem neuen Schlüsselpaar erneuerte CA weiterhin ohne weitere Maßnahmen mit einer bestehenden OCSP-Responder-Konfiguration funktioniert.

Dies ist wichtig zu wissen, da in ADCS-Umgebungen die Einstellung „UseDefinedCACertInRequest“ mitunter aktiviert ist. Dadurch kann der OCSP-Responder anfordern, dass sein Signaturzertifikat unter einem bestimmten CA-Zertifikat und Schlüsselpaar ausgestellt wird, anstatt automatisch das neueste Erneuerungsschlüsselpaar der CA zu verwenden. Dies erhöht die Komplexität des Betriebs ohne nennenswerten Nutzen in den meisten reinen Windows-Umgebungen und ist hauptsächlich relevant, wenn Drittanbieter-Clients oder Validierungsbibliotheken das Autorisierungsverhalten des Responders gemäß RFC 6960 strikt durchsetzen. Vor der Aktivierung dieser Einstellung sollten die Kompatibilitätsanforderungen anhand der verwendeten Client-Plattformen geprüft werden.

Die id-pkix-ocsp-nocheck-Erweiterung

Bei delegierten OCSP-Signaturzertifikaten besteht ein logisches Problem: Ein Client, der eine OCSP-Antwort validiert, müsste den Widerrufsstatus des Signaturzertifikats überprüfen, was eine separate OCSP-Abfrage erfordern würde, die wiederum die Überprüfung des Widerrufsstatus des Signaturzertifikats des Antwortenden erfordern würde, wodurch eine zirkuläre Abhängigkeit ohne klare Lösung entsteht.

RFC 6960 behandelt dieses Problem mit der Erweiterung „id-pkix-ocsp-nocheck“. Ist diese Erweiterung im Signaturzertifikat vorhanden, signalisiert sie OCSP-Clients, dass sie dem Responder für die gesamte Gültigkeitsdauer des Zertifikats vertrauen und keine Widerrufsprüfung durchführen sollen. Die Erweiterung sollte nicht kritisch sein und den Wert NULL haben.

RFC 6960 weist außerdem darauf hin, dass Zertifizierungsstellen, die ein solches Zertifikat ausstellen, sich darüber im Klaren sein sollten, dass die Kompromittierung des privaten Schlüssels des Antwortempfängers genauso schwerwiegend ist wie die Kompromittierung eines CA-Schlüssels, der zum Signieren von Sperrlisten verwendet wird – zumindest für die Gültigkeitsdauer dieses Zertifikats. Aus diesem Grund entscheiden sich Zertifizierungsstellen möglicherweise dafür, diese Zertifikate mit kurzer Gültigkeitsdauer auszustellen. erneuern sie häufig.

Die integrierte OCSP-Antwortsignatur Die Zertifikatvorlage in Windows ADCS enthält diese Erweiterung standardmäßig. Wenn Sie diese Vorlage dupliziert und Erweiterungen entfernt oder geändert haben, überprüfen Sie vor der Bereitstellung, ob id-pkix-ocsp-nocheck weiterhin vorhanden ist.

Die erforderliche EKU OID

Das Signaturzertifikat muss außerdem die OCSP-Signatur-OID für die erweiterte Schlüsselverwendung (1.3.6.1.5.5.7.3.9) enthalten. Andernfalls erkennen Clients das Zertifikat nicht als berechtigt zur Signierung von OCSP-Antworten an.

In Windows-Umgebungen kann die Registrierung für ein OCSP-Signaturzertifikat mit Fehlern wie CERT_E_INVALID_POLICY fehlschlagen, wenn eine Zertifizierungsstelle in der Zertifikatskette explizite EKU-Beschränkungen durchsetzt, die OCSP-Signaturen nicht zulassen. Dieses Problem tritt nicht auf, wenn die Zertifikate der Zertifizierungsstelle die Standardkonfiguration „Alle Anwendungsrichtlinien“ verwenden, die keine EKU-Beschränkungen vorsieht.

Wenn Ihre PKI-Hierarchie explizite EKU-Beschränkungen in CA-Zertifikaten verwendet, sollten Sie sicherstellen, dass die OCSP-Signatur-EKU (1.3.6.1.5.5.7.3.9) gegebenenfalls zugelassen ist. Diese Prüfung sollte proaktiv während der PKI-Planung und nicht erst im Falle eines Vorfalls durchgeführt werden.

OCSP für Offline- und Standalone-CAs

In einem Standard zweistufige PKI In dieser Hierarchie ist die Stammzertifizierungsstelle offline und die ausstellende Zertifizierungsstelle online. Eine Frage, die in vielen ADCS-Designprüfungen auftaucht, ist, ob die Stammzertifizierungsstelle einen eigenen OCSP-Responder benötigt.

In den meisten praktischen Anwendungen ist dies nicht der Fall. Root-CA-Zertifikate sind langlebig, werden selten widerrufen und von Client-Truststores direkt als vertrauenswürdig eingestuft, anstatt über OCSP validiert zu werden. Ein CRL-basierter Widerruf für die Root-CA ist im Allgemeinen ausreichend.

Für die ausstellende Zertifizierungsstelle (CA) muss der OCSP-Responder nicht auf demselben Server wie die CA gehostet werden. Ein dedizierter Windows Server mit der Rolle „Online Responder“ kann als OCSP-Responder dienen, indem er die CRL von der ausstellenden CA importiert und Antworten mit einem delegierten OCSP-Signaturzertifikat signiert.

Für eigenständige Zertifizierungsstellen (CA-Umgebungen, d. h. CAs, die nicht in Active Directory integriert sind) ist die automatische Registrierung nicht verfügbar. Daher müssen OCSP-Antwortsignaturzertifikate manuell angefordert und erneuert werden, typischerweise mithilfe von Tools wie certreq.exe. Die Zertifikatsanforderung muss eine INF-Konfigurationsdatei enthalten, die sowohl die OCSP Signing EKU (OID 1.3.6.1.5.5.7.3.9) als auch die Erweiterung „id-pkix-ocsp-nocheck“ explizit einschließt. Bei einer eigenständigen CA ist die Erweiterung „id-pkix-ocsp-nocheck“ standardmäßig nicht in den ausgestellten Zertifikaten enthalten. Vor dem Absenden der Anforderung müssen Sie das entsprechende Flag auf der CA mit dem folgenden Befehl aktivieren:

certutil -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

Starten Sie den CA-Dienst nach Ausführung dieses Befehls neu. Ohne aktiviertes Flag fügt die eigenständige CA die Erweiterung „id-pkix-ocsp-nocheck“ nicht in das ausgestellte Signaturzertifikat ein, was dazu führt, dass Clients versuchen, die Gültigkeit des Signaturzertifikats selbst zu überprüfen und möglicherweise ein rekursives Validierungsverhalten auslösen.

Da die Erneuerung in Standalone-Umgebungen nicht automatisiert erfolgt, ist eine proaktive Überwachung der OCSP-Signatur erforderlich. Gültigkeitsdauer des Zertifikats ist unerlässlich, um Betriebsunterbrechungen zu vermeiden.

Wie Verschlüsselungsberatung helfen kann

Die Implementierung von OCSP in einer Unternehmensumgebung erfordert weit mehr als die Installation der Online-Responder-Rolle und die Veröffentlichung einer URL. Reale Implementierungen setzen eine sorgfältige Planung hinsichtlich Responder-Design, Verwaltung von Signaturzertifikaten, Aktualität der Widerrufsdaten, Skalierbarkeit, Überwachung und Interoperabilität über verschiedene Client-Plattformen hinweg voraus. Fehlkonfigurationen bleiben oft unbemerkt, bis ein Ausfall der Zertifikatsvalidierung oder ein Sicherheitsvorfall sie aufdeckt.

Bei Encryption Consulting, unsere PKI-Dienste Unser Team arbeitet mit Organisationen aus den Bereichen Finanzdienstleistungen, Gesundheitswesen, öffentliche Verwaltung, Technologie, Einzelhandel, Energie und vielen weiteren Branchen zusammen, um OCSP-Infrastrukturen zu entwickeln, bereitzustellen und zu validieren, die unter realen Bedingungen zuverlässig funktionieren. Wir prüfen die Einhaltung von RFC 6960 in Ihrer Zertifizierungsstellenhierarchie, identifizieren Probleme in der OCSP-Signaturzertifikatskette, bevor es zu Ausfällen kommt, und konfigurieren alle Einstellungen gemäß den Best Practices der Branche und den Anforderungen Ihres Unternehmens.

Darüber hinaus hilft unsere CertSecure Manager-Plattform bei der Automatisierung Zertifikatslebenszyklusverwaltung und die Transparenz in unternehmensweiten PKI-Umgebungen zu verbessern, den operativen Aufwand zu reduzieren und gleichzeitig die Zertifikatsverwaltung und die Bereitschaft zum Zertifikatswiderruf zu stärken.

Ob Sie OCSP zum ersten Mal einsetzen, eine bestehende Implementierung im Vorfeld eines Audits absichern oder Ihre Widerrufsinfrastruktur vorbereiten für kürzere ZertifikatslebensdauerUnser Team verfügt über die praktische Erfahrung mit ADCS und plattformübergreifender PKI, um Ihnen dabei zu helfen, alles richtig zu machen.

Kontaktieren Sie unser Team unter [E-Mail geschützt] um zu starten.

Fazit

OCSP spielt eine entscheidende Rolle, um die Validierung von Zertifikatssperrinformationen in Echtzeit in modernen PKI-Umgebungen zu gewährleisten. Obwohl das Protokoll selbst unkompliziert ist, erfordert der Betrieb einer zuverlässigen OCSP-Infrastruktur sorgfältige Beachtung der Responder-Konfiguration, des Vertrauens in die Signaturzertifikate, der Aktualität der Sperrinformationen, der Skalierbarkeit und des Clientverhaltens im Fehlerfall.

Wie dieser Leitfaden gezeigt hat, wirken sich verschiedene fortgeschrittene Konfigurationsbereiche direkt auf Sicherheit und Betriebssicherheit aus. Die deterministische Antwortverarbeitung stellt sicher, dass der Responder für Seriennummern, die nie von der Zertifizierungsstelle ausgestellt wurden, UNKNOWN anstatt GOOD zurückgibt. Die korrekte, RFC-6960-konforme Konfiguration von Signaturzertifikaten gewährleistet Interoperabilität zwischen verschiedenen Plattformen und Client-Implementierungen. Betriebliche Kontrollmechanismen wie die Überwachung der Aktualität von Antworten, die Verwaltung der OCSP-Signaturzertifikatserneuerung und die Skalierung des Responders gewinnen mit steigendem Zertifikatsvolumen und sinkender Zertifikatsgültigkeitsdauer zunehmend an Bedeutung.

OCSP-Stapling verbessert darüber hinaus sowohl den Datenschutz als auch die Leistung, indem es den clientseitigen Antwortverkehr reduziert und die TLS-Handshake-Latenz minimiert, wodurch es zu einer wichtigen Komponente der modernen Webinfrastruktur wird.

Letztendlich geht es bei einer robusten OCSP-Implementierung nicht nur um die Ermöglichung der Widerrufsprüfung, sondern auch darum, sicherzustellen, dass Widerrufsinformationen unter realen Bedingungen korrekt, vertrauenswürdig, verfügbar und betrieblich nachhaltig bleiben. Organisationen, die in eine gut konzipierte und kontinuierlich überwachte OCSP-Infrastruktur investieren, reduzieren das Risiko unbemerkter Widerrufsfehler erheblich und stärken die allgemeine Vertrauenswürdigkeit ihrer PKI-Umgebung.