Einführung in OCSP-Stapling

Einführung

SSL/TLS-Zertifikate fungieren als digitale IDs, mit denen ein Browser die Identität einer Website bestätigen kann, bevor Daten ausgetauscht werden. Dieses Vertrauen basiert unter anderem auf dem Widerrufsmechanismus: Dieser Mechanismus informiert den Browser, wenn ein Zertifikat nicht mehr sicher ist, beispielsweise weil ein Server kompromittiert wurde, ein Schlüssel versehentlich offengelegt wurde oder eine Zertifizierungsstelle (CA) das Zertifikat irrtümlich ausgestellt hat. OCSP Stapling wurde entwickelt, um diesen Widerrufsstatus schnell und vertraulich zu übermitteln. Die CA-Landschaft, die diesen Mechanismus unterstützt, hat sich jedoch seit seiner Etablierung als Best Practice erheblich verändert. Dieser Leitfaden beschreibt die genauen Änderungen.

Die 50-Wort-Version

OCSP Stapling ermöglicht es einem Webserver, eine signierte Zertifikatsstatusantwort vorab von seiner Zertifizierungsstelle abzurufen und direkt an den TLS-Handshake anzuhängen. Dadurch erhält der Browser des Besuchers den Widerrufsstatus, ohne die Zertifizierungsstelle selbst kontaktieren zu müssen. Dies verbessert Geschwindigkeit und Datenschutz gegenüber Standard-OCSP, funktioniert jedoch nur, wenn die ausstellende Zertifizierungsstelle noch einen OCSP-Responder betreibt.

Im Überblick

• Durch OCSP Stapling entfällt die Notwendigkeit, dass ein Browser die Zertifizierungsstelle direkt kontaktieren muss. Dadurch werden sowohl die Verbindungsgeschwindigkeit als auch der Datenschutz für Besucher im Vergleich zu Standard-OCSP verbessert.
• Let's Encrypt, die Zertifizierungsstelle hinter etwa der Hälfte aller TLS-Zertifikate im Web, hat die Ausstellung von OCSP Must-Staple-Zertifikaten am 30. Januar 2025 deaktiviert und ihre OCSP-Responder am 6. August 2025 vollständig abgeschaltet.
• Das bedeutet, dass OCSP Stapling für kein aktuelles Let's Encrypt-Zertifikat etwas zum Stappen hat; Server, die sich für diese Zertifikate darauf verlassen, müssen stattdessen auf Zertifikatssperrlisten (CRLs) umsteigen.
• Google Chrome, der am weitesten verbreitete Browser, hat das OCSP Must-Staple Hard-Fail-Verhalten nie nativ erzwungen, sondern sich stattdessen auf seinen eigenen CRLSet-Mechanismus verlassen, der den Schutz, den Must-Staple tatsächlich bietet, selbst dann einschränkt, wenn eine Zertifizierungsstelle es noch unterstützt.
• Ob OCSP Stapling für ein bestimmtes Zertifikat noch sinnvoll ist, hängt nun ausschließlich davon ab, ob die ausstellende Zertifizierungsstelle noch einen OCSP-Responder betreibt. Dies muss für jede Zertifizierungsstelle einzeln überprüft werden und kann nicht einfach angenommen werden.

Warum dies ein Update benötigt

Let's Encrypt kündigte im Dezember 2024 an, OCSP im Laufe des Jahres 2025 vollständig abzuschaffen, und setzte dies termingerecht um. Am 30. Januar 2025 wurde die Ausstellung neuer Zertifikate mit der OCSP-Must-Staple-Erweiterung deaktiviert. Am 7. Mai 2025 wurden OCSP-URLs vollständig aus neu ausgestellten Zertifikaten entfernt. Am 6. August 2025 wurden die OCSP-Responder endgültig abgeschaltet und vollständig auf Zertifikatssperrlisten (CRLs) umgestellt. Für Server, die ein nach diesem Zeitpunkt ausgestelltes Let's-Encrypt-Zertifikat verwenden, ist OCSP-Stapling nicht langsamer oder weniger datenschutzfreundlich, sondern schlichtweg nicht mehr verfügbar, da kein Responder mehr vorhanden ist, von dem eine Antwort gestapelt werden könnte.

Die am 2. Juli 2025 veröffentlichte DigiCert Trust Pulse Survey ergab, dass fast die Hälfte aller Unternehmen im vergangenen Jahr einen Zertifikatsausfall erlebte. 37.5 % der Vorfälle waren auf abgelaufene Zertifikate zurückzuführen, und 18.5 % der betroffenen Unternehmen meldeten Verluste von über 250,000 US-Dollar. Ein Server, der weiterhin OCSP-Antworten für eine Zertifizierungsstelle abruft und speichert, die diese nicht mehr bereitstellt, trägt unbemerkt und leicht zu übersehen zu genau diesem Ausfallrisiko bei. Denn eine fehlerhafte Konfiguration oder ein fehlerhaftes Speichern der Antworten kann Verbindungen je nach Client-Einstellungen beeinträchtigen oder unterbrechen.

Gleichzeitig verkürzt sich die Gültigkeitsdauer von Zertifikaten. Gemäß der CA/Browser Forum-Abstimmung SC-081v3 vom 11. April 2025 sinkt die Gültigkeit öffentlich vertrauenswürdiger TLS-Zertifikate ab dem 15. März 2026 von 398 auf 200 Tage, ab dem 15. März 2027 auf 100 Tage und ab dem 15. März 2029 auf 47 Tage. Kürzere Gültigkeitsdauern verringern den Zeitraum, in dem ein Widerrufsmechanismus – ob Standard oder nicht – tatsächlich relevant ist. Dies ist ein Grund für die branchenweite Abkehr von OCSP.

Was ist OCSP-Stapling?

OCSP-Stapling (Online Certificate Status Protocol) ist ein Internetstandard, der den Sperrstatus eines X.509-Zertifikats überprüft , ohne dass der Client die Zertifizierungsstelle direkt kontaktieren muss. Stattdessen fordert der Webserver regelmäßig eine signierte Statusantwort vom OCSP-Responder der Zertifizierungsstelle an und fügt diese während des TLS-Handshakes dem Zertifikat hinzu. Erhält der Browser den Sperrstatus, warnt er den Benutzer und kann die Verbindung blockieren, bevor vertrauliche Informationen ausgetauscht werden.

Der OCSP-Validierungsablauf für Heftklammern

Die folgende Tabelle beschreibt jeden einzelnen Schritt des Prozesses und was passiert, wenn etwas schiefgeht.

Schritt	Was geschieht	Fehlermodus	Überwachungssignal
1. Ausstellung des Zertifikats	Die Zertifizierungsstelle stellt ein Zertifikat aus, das eine OCSP-Responder-URL enthält und damit signalisiert, dass OCSP für dieses Zertifikat unterstützt wird.	Das Zertifikat wird ohne OCSP-URL ausgestellt, wie es Let's Encrypt nun für alle neuen Zertifikate handhabt.	Die Zertifikatsprüfung zeigt kein OCSP-Feld für den Zugriff auf Autoritätsinformationen an.
2. Verfügbarkeit von OCSP-Respondern	Der OCSP-Responder der CA beantwortet Statusanfragen und veröffentlicht regelmäßig aktualisierte Statusmeldungen.	Die Zertifizierungsstelle hat ihren OCSP-Responder vollständig eingestellt, ebenso wie Let's Encrypt am 6. August 2025.	Eine direkte Anfrage an die Responder-URL führt zu einem Timeout oder gibt einen Fehler zurück.
3. Der Server ruft eine Antwort ab und speichert sie im Cache.	Der Webserver fordert eine signierte OCSP-Antwort an und speichert sie zur Wiederverwendung über Clientverbindungen hinweg.	Der Server kann den Responder nicht erreichen und hat keine zwischengespeicherte Antwort zum Staple-Vorgang.	Serverprotokolle zeigen wiederholte OCSP-Abruffehler an.
4. TLS-Handshake und -Stapeln	Der Server fügt die zwischengespeicherte OCSP-Antwort während des Handshakes dem Zertifikat hinzu.	Der Server präsentiert ein Zertifikat ohne Klammern, wodurch Clients gezwungen werden, entweder auf das Standard-OCSP zurückzugreifen oder überhaupt keine Widerrufsprüfung durchzuführen.	SSL Labs oder vergleichbare Scan-Berichte geben für OCSP-Stapling „Nein“ oder „Nicht unterstützt“ an.
5. Kundenbestätigung	Der Browser prüft die Signatur und den Status (gültig, widerrufen oder unbekannt) der angehängten Antwort.	Veraltete oder abgelaufene Staples veranlassen manche Clients dazu, auf eine direkte OCSP-Abfrage zurückzugreifen oder die Verbindung trotzdem zu akzeptieren.	Clientseitige TLS-Fehlerprotokolle oder Browser-Entwicklertools kennzeichnen Stapling-Probleme

Zertifikatsantworttypen

Antwort	Bedeutung	Browserverhalten
Gut	Der OCSP-Responder erkennt die Seriennummer des Zertifikats und bestätigt, dass es nicht widerrufen wurde.	Die Verbindung wird normal hergestellt
Widerrufen	Das Zertifikat wurde von der ausstellenden Zertifizierungsstelle ausdrücklich widerrufen.	Unverzügliche Beendigung; der Browser blockiert die Verbindung und warnt den Benutzer.
Unbekannt	Der Responder erkennt das Zertifikat nicht, häufig weil es gegen eine andere Zertifizierungsstelle geprüft werden muss als die, für die es konfiguriert ist.	Sanfter Stopp; das Verhalten variiert je nach Browser und kann die Verbindung unter Umständen aufrechterhalten.

Vor- und Nachteile von OCSP-Stapling

Vorteile

• Verbesserte Leistung. Der Server speichert die OCSP-Antwort im Cache und verwendet sie wieder, wodurch der zusätzliche Roundtrip vermieden wird, den ein Client sonst für jede Verbindung zur Zertifizierungsstelle durchführen müsste.
• Verbesserte Privatsphäre. Da die Zertifizierungsstelle die periodische Aktualisierungsanfrage des Servers beantwortet und nicht für jeden einzelnen Besucher eine Anfrage stellt, kann sie nicht erkennen, welche spezifischen Benutzer welche Seiten besuchen.
• Ressourceneffizienz. Stapling benötigt weniger Netzwerkressourcen als entweder Standard-OCSP-Abfragen pro Besucher oder das Herunterladen einer vollständigen Zertifikatssperrliste.

Nachteile

• Vollständige Abhängigkeit vom OCSP-Responder der ausstellenden Zertifizierungsstelle. Wenn dieser Antwortdienst eingestellt wird, wie es jetzt bei Let's Encrypt der Fall ist, hat das Stapling einfach nichts mehr abzurufen, unabhängig davon, wie gut der Server konfiguriert ist.
• Begrenzte Kettenabdeckung. Beim Basic OCSP Stapling werden Zwischenzertifikate in der Kette in der Regel nicht überprüft, allerdings wird dies bei Servern, die Multi-Stapling und TLS 1.3-Unterstützung implementieren, behoben.
• Aktualisierungsverzögerung. Zwischen den Aktualisierungszyklen besteht eine zeitliche Lücke, sodass ein Zertifikat, das kurz nach der letzten Aktualisierung widerrufen wurde, möglicherweise noch bis zum nächsten Abruf einen veralteten „gültigen“ Status anzeigt.

Warum Must-Staple ebenfalls an Bedeutung verliert

Die OCSP-Must-Staple-Erweiterung wurde entwickelt, um eine spezifische Lücke zu schließen: Ohne sie kann ein Server die Staple-Angabe einfach weglassen, und ein Browser hat keine Möglichkeit zu erkennen, dass eine vorhanden sein sollte. Must-Staple führt zu einem Verbindungsabbruch, wenn keine gültige Staple-Angabe angehängt ist, und zwingt Server theoretisch dazu, weiterhin korrekt zu stappen. In der Praxis war ihre Nützlichkeit jedoch stets durch die uneinheitliche Browserunterstützung eingeschränkt, und sie verschwindet nun aus einem direkteren Grund vollständig aus dem Ökosystem. Google Chrome, der Browser mit dem größten Anteil am Webverkehr, hat das Hard-Fail-Verhalten von Must-Staple nie nativ erzwungen, sondern sich stattdessen auf seinen eigenen CRLSet-Mechanismus verlassen, um Sperrinformationen in großem Umfang zu verteilen. Darüber hinaus hat Let's Encrypt die Ausstellung neuer Must-Staple-Zertifikate am 30. Januar 2025 als ersten Schritt seiner umfassenderen OCSP-Abschaltung deaktiviert. Angesichts der eingeschränkten Browserunterstützung und der Tatsache, dass die größte Zertifizierungsstelle keine Must-Staple-Zertifikate mehr ausstellt, ist Must-Staple keine Kontrollmaßnahme mehr, auf die man sich in Zukunft verlassen sollte.

Checkliste zur Überwachung der OCSP-Heftgeräte-Gesundheit

1. Prüfen Sie, welche Zertifizierungsstelle (CA) in Ihrer Umgebung die einzelnen Zertifikate ausgestellt hat und ob diese CA noch einen OCSP-Responder betreibt.
2. Bei Zertifikaten von einer Zertifizierungsstelle, die OCSP eingestellt hat, deaktivieren Sie die Stapling-Konfiguration für diese Zertifikate und vergewissern Sie sich stattdessen, dass die CRL-Prüfung ordnungsgemäß konfiguriert ist.
3. Führen Sie regelmäßig eine Überprüfung der Widerrufsrechte für jeden öffentlich zugänglichen Hostnamen durch, nicht nur bei der Erstinstallation.
4. Überwachen Sie die Serverprotokolle auf wiederholte OCSP-Abruffehler, die entweder auf einen Ausfall des Responders oder auf ein Zertifikat einer Zertifizierungsstelle hinweisen, die OCSP nicht mehr unterstützt.
5. Entfernen Sie alle verbleibenden OCSP Must-Staple-Konfigurationen auf Zertifikaten von Zertifizierungsstellen, die die Erweiterung als veraltet markiert haben, da eine Hard-Fail-Einstellung ohne zu bindende Elemente Verbindungen vollständig unterbrechen kann.
6. Prüfen Sie diese Checkliste immer dann erneut, wenn eine Zertifizierungsstelle in Ihrer Umgebung eine Infrastrukturänderung ankündigt, und zwar nicht nur nach einem festen Kalenderplan.

So prüfen Sie, ob OCSP-Stapling aktiviert ist

Die Unterstützung von OCSP-Stapling hängt heutzutage von der verwendeten Webserver-Software ab, beispielsweise von einer aktuell unterstützten Version von IIS, Nginx, Apache oder Caddy, und nicht von einer bestimmten älteren Betriebssystemversion. Jede moderne, aktiv gepflegte Serverplattform unterstützt Stapling; die praktische Frage ist, ob es korrekt konfiguriert ist und ob die ausstellende Zertifizierungsstelle (CA) noch einen Responder hat, von dem sie die Zertifikate abrufen kann.

Schritt 1: Gehen Sie zu SSL Labs by Qualys.

Schritt 2: Aktivieren Sie das Kontrollkästchen, um die Veröffentlichung der Ergebnisse auf der öffentlichen Ergebnistafel zu vermeiden, falls die Domain privat bleiben soll.

Schritt 3: Geben Sie den Domainnamen ein, um den Scan zu überprüfen, und senden Sie ihn ab.

Schritt 4: Sobald der Scan abgeschlossen ist, überprüfen Sie den Abschnitt „Widerrufsinformationen“, in dem CRL- und OCSP-Details aufgeführt sind.

Schritt 5: Überprüfen Sie die Zeile „OCSP-Stapling“. Ein „Ja“ bedeutet, dass Stapling aktiv ist. Ein „Nein“ bedeutet, dass es deaktiviert ist, das Zertifikat aber weiterhin OCSP unterstützt. Das Ergebnis „Nicht unterstützt“ kann bedeuten, dass die ausstellende Zertifizierungsstelle (CA) selbst kein OCSP mehr anbietet. Dies ist beispielsweise bei Zertifikaten von Let's Encrypt der Fall. Überprüfen Sie daher die ausstellende CA, bevor Sie von einer Serverfehlkonfiguration ausgehen.

Wen sollte das interessieren?

Die Abkehr von OCSP verändert konkrete Konfigurationsentscheidungen in verschiedenen Rollen.

PKI-Administratoren

Die Konfiguration für den Zertifikatswiderruf auf Serverebene beibehalten. Maßnahmen: Jedes Zertifikat hinsichtlich seiner ausstellenden Zertifizierungsstelle prüfen und die OCSP-Stapling- oder Must-Staple-Konfiguration für alle Zertifizierungsstellen entfernen, die die OCSP-Unterstützung eingestellt haben.

Sicherheitsarchitekten

Legen Sie den Standard für die Widerrufsprüfung der Organisation fest. Maßnahmenpunkt: Definieren Sie eine CRL-basierte Ausweichrichtlinie für jede Zertifizierungsstelle, die OCSP nicht mehr unterstützt, anstatt dies den einzelnen Serverteams zur eigenständigen Ermittlung zu überlassen.

Plattformteams

Sie sind für die Server- und Load-Balancer-Konfiguration verantwortlich. Handlungsempfehlung: Führen Sie eine Überprüfung aller öffentlich zugänglichen Hostnamen auf OCSP-Sperrzertifikate durch und korrigieren Sie die Konfiguration aller Hosts, die noch für OCSP-Stapling mit einer Zertifizierungsstelle konfiguriert sind, die dies nicht mehr unterstützt.

Compliance-Teams

Prüfen Sie, ob die Prüfdokumentation das aktuelle Verhalten der Zertifizierungsstelle widerspiegelt. Maßnahmenhinweis: Aktualisieren Sie alle Nachweise zur Einhaltung der Vorschriften, die OCSP Stapling noch als Standard-Widerrufsmechanismus angeben, falls die betreffende Zertifizierungsstelle auf CRLs umgestellt hat.

CISOS

Wägen Sie den Aufwand für die Aufrechterhaltung der Widerrufskonfiguration pro Zertifizierungsstelle gegen das Risiko einer unbemerkten Fehlkonfiguration ab. Handlungsempfehlung: Nutzen Sie die Abschaltung des OCSP-Dienstes von Let's Encrypt als Anlass, zu überprüfen, ob die Widerrufsprüfung für alle Zertifikate, nicht nur für neu ausgestellte, aktuell ist.

Unsere Einschätzung: Wie Verschlüsselungsberatung das Zertifikatssperrmanagement unterstützt

OCSP-Stapling war eine deutliche Verbesserung gegenüber Standard-OCSP, solange Zertifizierungsstellen (CAs) Responder dahinter betrieben. Da die größte CA im Web nun vollständig auf OCSP verzichtet, stellt sich für die meisten Organisationen nicht mehr die Frage, wie Stapling korrekt konfiguriert wird, sondern welche Zertifikate es überhaupt noch benötigen.

Unsere CertSecure Manager- Plattform bietet Teams eine vollständige Bestandsaufnahme der Maschinenidentitäten und die Möglichkeit zur Zertifikatserkennung. Dadurch wird eine Infrastrukturänderung auf CA-Ebene wie diese als geplante Bestandsaktualisierung und nicht als unerwarteter Ausfall wahrgenommen. Für Organisationen, die sich fragen, ob sie ihre Sperrinfrastruktur überhaupt intern verwalten sollen, bietet unsere PKI-as-a-Service- Plattform die Lösung. Sie betreibt die CA-Hierarchie inklusive Sperrveröffentlichung auf FIPS 140-3 Level 3 HSM-gestützten Schlüsseln, während Ihre Organisation Eigentum und Kontrolle behält. Einen detaillierteren Vergleich von OCSP und CRLs finden Sie in unserem Leitfaden zu OCSP vs. CRL . Ein verwandtes Windows-spezifisches Detail, das in unserem Beitrag zur OCSP Magic Number erläutert wird, ist der Schwellenwert, der Clients im Hintergrund von OCSP auf CRL-Prüfung umstellt. Im Bereich der Krypto-Agilität helfen unser PQC Center of Excellence und unsere PQC Readiness Assessment Teams bei der Planung für eine Zukunft, in der die Widerrufsinfrastruktur selbst eine postquantensichere Signatur benötigt. Unsere CBOM Secure Plattform zur kryptografischen Erkennung und Inventarisierung gibt Sicherheitsarchitekten Einblick in genau die Zertifikate in einer Umgebung, die noch von einer veralteten OCSP-Konfiguration abhängen.

Fazit

OCSP Stapling verbesserte das Standard-OCSP-Protokoll, indem es den Widerrufsstatus schneller und datenschutzfreundlicher übermittelte, ohne dass jeder Client die Zertifizierungsstelle (CA) direkt abfragen musste. Dieser Vorteil war jedoch stets an die Bedingung geknüpft, dass die ausstellende CA weiterhin einen OCSP-Responder betrieb, was bei der größten CA im Internet nicht mehr der Fall ist. Let's Encrypts schrittweise Abschaltung – von der Deaktivierung der Must-Staple-Zertifikatsausstellung im Januar 2025 bis zur vollständigen Abschaltung der OCSP-Responder im August 2025 – bedeutet, dass viele Organisationen nicht mehr die Stapling-Konfiguration optimieren, sondern Zertifikat für Zertifikat prüfen müssen, ob OCSP überhaupt noch verwendet wird.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dieser Einführung in das OCSP-Heften?

OCSP-Stapling verbessert die Geschwindigkeit und den Datenschutz bei der Überprüfung von Zertifikatssperrungen, funktioniert aber nur, wenn die ausstellende Zertifizierungsstelle noch einen OCSP-Responder betreibt. Let's Encrypt, die größte Zertifizierungsstelle im Internet, hat ihre OCSP-Responder am 6. August 2025 vollständig abgeschaltet, wodurch Stapling für ihre aktuellen Zertifikate nicht mehr verfügbar ist.

Warum ist das für PKI-Teams in Unternehmen wichtig?

Serverkonfigurationen, die auf der Annahme basieren, dass OCSP Stapling universell verfügbar ist, können nun für Zertifikate, die von Zertifizierungsstellen ausgestellt wurden, die OCSP eingestellt haben, stillschweigend funktionsunfähig sein, wodurch eine unüberwachte Lücke bei der Widerrufsprüfung entsteht.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Die manuelle Nachverfolgung, welche Zertifizierungsstelle welches Zertifikat ausgestellt hat und ob diese Zertifizierungsstelle OCSP noch unterstützt, ist nicht skalierbar, und eine veraltete OCSP Must-Staple-Konfiguration kann zu schwerwiegenden Verbindungsabbrüchen führen, sobald eine Zertifizierungsstelle überhaupt keine Antworten mehr liefert.

Welche Teams sollten für diese Änderung verantwortlich sein?

PKI-Administratoren sind für die Konfiguration der Sperrung auf Serverebene zuständig, Sicherheitsarchitekten legen den CRL-Fallback-Standard fest, Plattformteams sind für das Scannen und die Behebung von Fehlern verantwortlich, die Compliance-Abteilung überprüft die Genauigkeit der Dokumentation, und der CISO wägt das Gesamtrisiko ab.

Wie hängt das mit dem Zertifikatslebenszyklusmanagement zusammen?

Tools für das Zertifikatslebenszyklusmanagement, die nachverfolgen, welche Zertifizierungsstelle welches Zertifikat ausgestellt hat, ermöglichen es, betroffene Zertifikate schnell zu identifizieren, wenn eine Zertifizierungsstelle ihre Widerrufsinfrastruktur ändert, anstatt die Lücke erst durch einen Verbindungsfehler zu entdecken.

Wie sollten Organisationen ihren Erfolg messen?

Verfolgen Sie den Prozentsatz der öffentlich zugänglichen Hosts, bei denen die Widerrufsprüfung für ihre tatsächlich ausstellende Zertifizierungsstelle korrekt konfiguriert ist, und stellen Sie sicher, dass keine Hosts mehr für OCSP Stapling oder Must-Staple gegen eine Zertifizierungsstelle konfiguriert sind, die dies nicht mehr unterstützt.

Was sollte regelmäßig geprüft oder überwacht werden?

Prüfen Sie regelmäßig, welche Zertifizierungsstelle (CA) welches Zertifikat ausgestellt hat, ob diese CA noch einen OCSP-Responder betreibt, ob das Stapling, sofern konfiguriert, funktioniert und ob der CRL-Fallback für Zertifikate von CAs, die nicht mehr auf OCSP setzen, korrekt eingerichtet ist.

Welche Auswirkungen hat dieses Thema auf Cloud-, Hybrid- oder Multi-CA-PKI?

In einer Umgebung, in der Zertifikate von mehreren Zertifizierungsstellen verwendet werden, sind möglicherweise unterschiedliche Widerrufskonfigurationen für jede einzelne erforderlich, da die Einstellung von OCSP durch eine Zertifizierungsstelle nicht bedeutet, dass alle Zertifizierungsstellen in einer Multi-CA- oder Hybridumgebung dasselbe getan haben.

Welche häufigen Fehler sollten Teams vermeiden?

Zu den häufigsten Fehlern gehören die Annahme, dass OCSP Stapling bei allen Zertifizierungsstellen gleich funktioniert, das Aktivieren von OCSP Must-Staple bei Zertifikaten einer Zertifizierungsstelle, die keine OCSP-Antworten mehr ausstellt, und die Berücksichtigung der Betriebssystemversion eines Servers anstelle der aktuellen OCSP-Unterstützung der ausstellenden Zertifizierungsstelle als entscheidenden Faktor.

Was sollte vierteljährlich aktualisiert werden?

Aktualisieren Sie das Zertifikatsinventar und dessen Zuordnung zum aktuellen OCSP-Unterstützungsstatus jeder ausstellenden Zertifizierungsstelle, führen Sie erneut Sperrprüfungen gegen öffentlich zugängliche Hosts durch und prüfen Sie mindestens vierteljährlich auf neu angekündigte Änderungen der CA-Infrastruktur.