Warum HTTP für CRL-Endpunkte und OCSP in PKI besser ist als HTTPS 

Wer sich mit Cybersicherheit beschäftigt hat, kennt wahrscheinlich die goldene Regel: „Im Produktivbetrieb immer HTTPS verwenden“. Sie gilt als Standardempfehlung für die Sicherung der Webkommunikation – und das aus gutem Grund: HTTPS verschlüsselt Daten während der Übertragung. Anders ausgedrückt: HTTPS schützt sensible Informationen vor dem Abhören. Doch bei Public-Key-Infrastrukturen (PKI), insbesondere bei der Verwaltung von Zertifikatssperrungen, trifft diese Regel nicht immer zu. Wir von Encryption Consulting nutzen unsere langjährige Erfahrung in der Zusammenarbeit mit Fortune-500-Unternehmen, Bundesauftragnehmern und Cloud-nativen Unternehmen, um robuste PKI-Systeme zu entwickeln. Eine häufig gestellte Frage lautet: „Sollten wir nicht auch für unsere Sperrendpunkte wie CRLs und OCSP HTTPS verwenden?“

Die Antwort mag Sie überraschen: In diesen Fällen richtet HTTPS oft mehr Schaden als Nutzen an. Lassen Sie uns untersuchen, warum HTTP in PKI für Sperrendpunkte die bessere Wahl sein kann.

Worin besteht der Unterschied zwischen HTTP und HTTPS für CRL- und OCSP-Endpunkte? CRLs und OCSP-Antworten sind bereits von der ausstellenden Zertifizierungsstelle signiert. HTTPS fügt zwar Verschlüsselung hinzu, schafft aber kein zusätzliches Vertrauen. Die Bereitstellung über HTTPS kann sogar eine zirkuläre Abhängigkeit erzeugen, da die Validierung der HTTPS-Verbindung dieselbe Sperrprüfung erfordert, die sie eigentlich durchführen soll.

Executive Summary

CRLs und OCSP-Antworten werden von der ausstellenden Zertifizierungsstelle kryptografisch signiert. HTTPS bietet zwar Transportverschlüsselung, aber kein zusätzliches Vertrauen und kann eine Zirkelabhängigkeit erzeugen: Die Validierung der HTTPS-Verbindung zu einem Widerrufsendpunkt erfordert dieselbe Widerrufsprüfung, die dieser Endpunkt eigentlich beantworten soll. Aus diesem Grund rät RFC 5280 ausdrücklich von HTTPS für CRL-Verteilungspunkte und URLs für den Zugriff auf Zertifizierungsstelleninformationen ab. Mit dem CA/Browser Forum-Abstimmungsantrag SC-063v4, der im März 2024 in Kraft trat, wurde OCSP für Zertifizierungsstellen optional und CRLs obligatorisch. Der Abstimmungsantrag SC-081v3 aus dem Jahr 2025 sieht eine schrittweise Reduzierung der Gültigkeit öffentlicher TLS-Zertifikate auf 47 Tage bis März 2029 vor. Beide Änderungen verringern die Abhängigkeit von Echtzeit-Widerrufsprüfungen. HTTPS auf einem Widerrufsendpunkt ist gelegentlich die richtige Wahl, beispielsweise für datenschutzsensible OCSP-Abfragen oder streng kontrollierte, unabhängig validierte Umgebungen. Standardmäßig sollte jedoch einfaches HTTP mit engem Caching oder, noch besser, OCSP-Stapling verwendet werden, wodurch die Live-Abfrage vollständig entfällt.

Widerrufsinformationen werden von der Zertifizierungsstelle digital signiert

Wird ein Zertifikat widerrufen, beispielsweise aufgrund eines kompromittierten Schlüssels oder eines Richtlinienverstoßes, muss die ausstellende Zertifizierungsstelle (CA) die vertrauenden Parteien benachrichtigen. Dies geschieht im Wesentlichen auf zwei Wegen. Zertifikatssperrlisten (CRLs) sind signierte Dateien, die regelmäßig veröffentlicht werden und alle widerrufenen Zertifikate auflisten. Alternativ bietet das Online Certificate Status Protocol (OCSP) Echtzeit-Statusabfragen für einzelne Zertifikate. Beiden Methoden ist gemeinsam, dass die CA die Zertifikate kryptografisch signiert. Diese Signatur gewährleistet die Authentizität und Integrität der Daten, unabhängig davon, ob sie über HTTP, HTTPS oder sogar einen herkömmlichen USB-Stick übertragen werden.

Wenn jemand versucht, eine CRL- oder OCSP-Antwort während der Übertragung zu manipulieren, schlägt die Validierungsprüfung der vertrauenden Partei fehl und die Daten werden sofort abgelehnt. Was bringt HTTPS in diesem Zusammenhang? In den meisten Fällen nicht viel.

Ablauf der Widerrufsvalidierung: CRL vs. OCSP

Beide Mechanismen nutzen eine CA-Signatur anstelle einer Transportverschlüsselung, um Vertrauen herzustellen, aber die Schritte, die ein Client unternimmt, unterscheiden sich:

Schritt	CRL-Fluss	OCSP-Ablauf
1	Der Client liest die CDP-URL aus den Zertifikatserweiterungen.	Der Client liest die AIA-URL aus den Zertifikatserweiterungen.
2	Der Client lädt die vollständige, von der Zertifizierungsstelle signierte CRL-Datei herunter (eine Liste aller widerrufenen Seriennummern).	Der Client sendet eine einzelne Zertifikatsstatusanfrage an den OCSP-Responder.
3	Der Client prüft, ob die Seriennummer des Zertifikats in der Liste erscheint.	Der OCSP-Responder übermittelt einen signierten Echtzeit-Status (gut/widerrufen/unbekannt).
4	Der Client speichert die CRL bis zu seiner nächsten geplanten Aktualisierung im Cache (Feld „nextUpdate“).	Der Client oder der Server mit Stapling speichert die Antwort für ein ähnlich kurzes Zeitfenster im Cache.
5	Wird das Dokument während des Transports manipuliert, schlägt die Signaturprüfung der Zertifizierungsstelle fehl und die Sperrliste wird abgelehnt.	Wird die Sendung während des Transports manipuliert, schlägt die Signaturprüfung der Zertifizierungsstelle fehl und die Antwort wird abgelehnt.

Unerwartete Risiken von HTTPS in PKI

Man könnte sich fragen, warum HTTPS angesichts seiner Sicherheitsvorteile nicht standardmäßig verwendet wird. Die Antwort liegt in einem subtilen, aber entscheidenden Problem, das in RFC 5280 , dem Standard für X.509-Zertifikate und CRLs, beschrieben wird. Dieser Standard rät von der Verwendung von HTTPS für Certificate Distribution Points (CDPs) oder Authority Information Access (AIA)-Felder ab. Das Problem ist eine sogenannte zirkuläre Abhängigkeit in dem Szenario, in dem der CRL- oder OCSP-Endpunkt über HTTPS gehostet wird. Dieser HTTPS-Dienst benötigt ein Zertifikat, um Vertrauen herzustellen. Um ein Zertifikat zu validieren, muss die vertrauende Partei dessen Sperrstatus prüfen.

Wenn der Widerrufsstatus jedoch auf demselben HTTPS-Endpunkt gehostet wird, geraten wir in eine Endlosschleife. RFC 5280 bezeichnet dies als „unbegrenzte Rekursion“ und stellt kein bloßes theoretisches Problem dar. Vielmehr kann es zu Validierungsfehlern in der Praxis führen, Vertrauensketten unterbrechen und Dienste stören.

Wir beobachteten dieses Problem bei einem Bundesauftragnehmer, der strengen Anforderungen des US-Verteidigungsministeriums und des FedRAMP-Programms unterlag. Dessen Sicherheitsrichtlinie schrieb die Verwendung von HTTPS für alle Endpunkte vor, einschließlich CRLs und OCSP -Antworten. Leider führte diese Konfiguration zu Zertifikatsvalidierungsfehlern während des TLS-Handshakes, was wiederum zu Kaskadenausfällen in den Firewalls und Diensten führte. So fatal kann eine solche Zirkelabhängigkeit sein. Konkret wurde sie in diesem Fall durch die HTTPS-basierten Widerrufsendpunkte verursacht. Durch die Umgestaltung der Infrastruktur, sodass signierte CRLs und OCSP-Antworten über unverschlüsseltes HTTP bereitgestellt werden, konnten wir die Rekursionsschleife beseitigen und die Funktionalität wiederherstellen, ohne Kompromisse bei Sicherheit oder Compliance einzugehen.

Auf unserer PKI-as-a-Service-Plattform verfolgen wir einen ähnlichen Ansatz und stellen Sperrdaten über HTTP mit eingebetteten Signaturen und strengen Caching-Kontrollen bereit. Dies vereinfacht die Validierung in Cloud-Umgebungen und verhindert ähnliche Fehler.

Wann HTTPS die richtige Wahl sein könnte

Es gibt Szenarien, in denen HTTPS für Sperrendpunkte sinnvoll sein kann, diese erfordern jedoch sorgfältige Planung und Überlegung. Wenn Sie beispielsweise Datenschutzbedenken haben und beispielsweise Metadatenlecks verhindern möchten, die offenlegen, welche Zertifikate geprüft werden, können Sie mit HTTPS OCSP-Anfragen und -Antworten verschlüsseln. HTTPS ist auch in streng kontrollierten Umgebungen mit fixierten Zertifikaten sinnvoll, da Sie so sicherstellen können, dass der Sperrstatus des HTTPS-Zertifikats über einen separaten, unabhängigen Pfad validiert wird. Eine weitere Möglichkeit ist die Out-of-Band-Validierung, um zirkuläre Abhängigkeiten gänzlich zu vermeiden. Diese Fälle sind jedoch die Ausnahme und erfordern eine sorgfältige Architektur, um neue Risiken zu vermeiden.

Aktuelle CA/Browser-Forum- und Browserrichtlinien zu OCSP und CRLs

Die PKI-Widerrufspolitik hat sich in den letzten Jahren erheblich verändert, und jede Entscheidung zwischen HTTP und HTTPS für Widerrufsendpunkte sollte berücksichtigen, wohin sich die Branche entwickelt, und nicht nur, wo sie herkommt:

Datum	Ändern	Warum dies für CRL/OCSP-Endpunkte wichtig ist
August 2023 (gültig ab März 2024)	CA/Browser Forum-Abstimmung SC-063v4 macht OCSP optional und CRLs obligatorisch für öffentlich vertrauenswürdige Zertifizierungsstellen	CAs können nun vollständig auf OCSP-Responder verzichten und so mehr Verantwortung für Design und Überwachung auf CRL-Verteilungsstellen verlagern.
Oktober 2024	Das Root-Programm von Microsoft ermöglicht es jeder Zertifizierungsstelle, ihre eigene OCSP-Richtlinie festzulegen.	Unternehmen können nicht länger davon ausgehen, dass jede öffentlich vertrauenswürdige Zertifizierungsstelle noch OCSP anbietet.
April 2025	Mit dem Wahlvorschlag SC-081v3 wird ein gestaffelter Gültigkeitsplan für das TLS-Zertifikat festgelegt: 200 Tage (März 2026), 100 Tage (März 2027), 47 Tage (März 2029).	Kurzlebigere Zertifikate verkürzen die Gültigkeitsdauer einzelner zwischengespeicherter CRL- oder OCSP-Antworten.
Laufend	Kurzlebige Zertifikatsprofile mit einer Laufzeit von nur 7 Tagen werden nun unterstützt.	Manche vertrauende Parteien verzichten bei so kurzen Gültigkeitszeiträumen gänzlich auf die Prüfung des Live-Widerrufs.

Eine intelligentere Alternative ist OCSP-Stapling

Wenn Sie Live-OCSP-Abfragen vollständig vermeiden möchten, bietet sich OCSP-Stapling als bessere Option an . Dabei ruft der Server eine OCSP-Antwort ab, speichert sie im Cache und bindet sie während des TLS-Handshakes an das Zertifikat. So entfällt die Notwendigkeit für Clients, den OCSP-Responder direkt abzufragen. Dies verbessert die Performance durch weniger externe Aufrufe, erhöht den Datenschutz, da Validierungsdetails serverseitig verarbeitet werden, und steigert die Ausfallsicherheit, falls der OCSP-Responder vorübergehend nicht verfügbar ist.

Häufige Fehlermodi für CRL- und OCSP-Endpunkte

Das Verständnis dafür, wie die Widerrufsprüfung in der Praxis fehlschlägt, hilft dabei, Prioritäten für die Überwachung und die Entwicklungsarbeit zu setzen:

Fehlermodus	Typische Ursache	Auswirkungen	Mitigation
Zirkuläre Abhängigkeit / unbegrenzte Rekursion	CRL- oder OCSP-Endpunkt, der über HTTPS mit einem Zertifikat gehostet wird, dessen eigener Widerrufsstatus von demselben Endpunkt abhängt	Fehler beim TLS-Handshake, kaskadierende Validierungsfehler in abhängigen Diensten	Die Widerrufsdaten können über unverschlüsseltes HTTP übermittelt oder das Zertifikat des HTTPS-Endpunkts über einen unabhängigen, separaten Pfad validiert werden.
Veraltete CRL-Aktualisierung	CRL wurde nicht planmäßig neu generiert oder veröffentlicht.	Clients können die CRL als abgelaufen ablehnen und einen Soft-Fail auslösen, wobei das Zertifikat als gültig behandelt wird.	Automatisieren Sie die CRL-Generierung und -Veröffentlichung weit vor dem nächsten Update-Termin.
OCSP-Responder nicht verfügbar	Ausfall des Antwortservers, Netzwerkproblem oder Ratenbegrenzung unter Last	Clients mit Soft-Fail-Funktion akzeptieren das Zertifikat stillschweigend als gültig; Clients mit Hard-Fail-Funktion blockieren den Zugriff vollständig.	Setzen Sie hochverfügbare OCSP-Responder ein oder wechseln Sie zu OCSP-Stapling, um die Live-Abhängigkeit zu beseitigen.
OCSP-Antwortwiedergabe	Zwischengespeicherte „gültige“ OCSP-Antworten, die oft bis zu etwa 7 Tage gültig sind, werden nach dem Widerruf wiederverwendet.	Ein widerrufenes Zertifikat wird für den Rest des Gültigkeitszeitraums der zwischengespeicherten Antwort als gültig behandelt.	Verkürzung der Gültigkeitsdauer von OCSP-Antworten und Ermöglichung des Zusammenführens mit neuen Antworten
Metadatenleck über OCSP	Unverschlüsselte OCSP-Anfragen geben Aufschluss darüber, welche Zertifikate und damit auch welche Websites ein Client validiert.	Gefährdung der Privatsphäre für jeden, der den Datenverkehr zum OCSP-Responder beobachtet	Verwenden Sie OCSP-Stapling oder verschlüsseln Sie OCSP-Anfragen ausschließlich über einen unabhängig validierten HTTPS-Pfad.

Checkliste zur Überwachung von Widerrufsendpunkten

• Prüfen Sie, ob die in den Zertifikats-CDP/AIA-Erweiterungen veröffentlichten CRL- und OCSP-Endpunkt-URLs korrekt aufgelöst werden und antworten.
• Überwachen Sie die CRL-nextUpdate-Felder und geben Sie rechtzeitig vor dem Ablauf einer CRL eine Warnung aus.
• Die Verfügbarkeit und Antwortlatenz des OCSP-Responders sollten getrennt von der allgemeinen Webserverüberwachung verfolgt werden.
• Prüfen Sie bei jeder planmäßigen Überprüfung, ob die CRL- und OCSP-Antworten von der ausstellenden Zertifizierungsstelle korrekt signiert wurden.
• Die Endpunkte zur Bestätigung des Widerrufs werden über normales HTTP bereitgestellt, es sei denn, ein unabhängiger, außerhalb des regulären Datenverkehrs liegender Validierungspfad für die Verwendung von HTTPS ist dokumentiert.
• Prüfen Sie, ob ein absichtlich widerrufenes Prüfungszertifikat sowohl von CRL als auch von OCSP korrekt als widerrufen gemeldet wird.
• Prüfen Sie, ob eine der vertrauenden Parteien in der Umgebung für die Prüfung auf Soft-Fail- bzw. Hard-Fail-Widerruf konfiguriert ist.
• Prüfen Sie, ob OCSP-Stapling aktiviert ist und, sofern unterstützt, planmäßig aktualisiert wird.
• Verfolgen Sie anstehende Änderungen der Gültigkeits- und Widerrufsrichtlinien von Zertifizierungsstellen/Browserforen, die Ihre ausstellenden Zertifizierungsstellen betreffen.
• Integrieren Sie die Überprüfung von Widerrufsendpunkten in dieselbe SIEM- oder Überwachungspipeline, die auch für das Zertifikatslebenszyklusmanagement verwendet wird.

Wie Verschlüsselungsberatung PKI für Sie nutzbar macht

Bei Encryption Consulting sprechen wir nicht nur über Standards, wir entwickeln Systeme, die diese in die Praxis umsetzen. Ob Sie Microsoft ADCS einsetzen , cloudbasierte Zertifizierungsstellen wie AWS Private CA oder Azure Key Vault nutzen, Open-Source-Lösungen wie EJBCA verwenden oder unsere PKI-as-a-Service- Plattform einsetzen – wir gewährleisten eine sichere und zuverlässige Infrastruktur für den Zertifikatssperrungsprozess. Wir entwickeln Systeme, die signierte Sperrdaten über HTTP ohne Validierungsfehler übertragen, implementieren hochverfügbare OCSP- und CRL-Responder und integrieren Sperrprüfungen in CI/CD-Pipelines und Zero-Trust-Umgebungen. Unsere CertSecure Manager- Plattform automatisiert das Zertifikatslebenszyklusmanagement und sorgt so für einen reibungslosen Ablauf Ihrer Prozesse. Vor allem aber helfen wir Ihnen, Vertrauensschleifen zu vermeiden, indem wir jeden HTTPS-Endpunkt sorgfältig und unabhängig validieren.

Glossar der CRL- und OCSP-Begriffe

Bedingungen	Definition
Zertifikatsperrliste (CRL)	Eine digital signierte Datei, die von einer Zertifizierungsstelle veröffentlicht wird und die Seriennummern aller Zertifikate auflistet, die sie vor deren Ablaufdatum widerrufen hat.
Online Certificate Status Protocol (OCSP)	Ein Protokoll, das es einem Client ermöglicht, den Responder einer Zertifizierungsstelle nach dem Echtzeit-Widerrufsstatus eines einzelnen Zertifikats abzufragen.
OCSP-Heften	Eine Technik, bei der ein Server seine eigene OCSP-Antwort abruft und zwischenspeichert und sie dann während des TLS-Handshakes direkt an die Clients übermittelt, wodurch die Notwendigkeit einer separaten Client-zu-Responder-Anfrage entfällt.
CRL-Verteilungspunkt (CDP)	Eine Zertifikatserweiterung, die die URL enthält, unter der Clients die Sperrliste (CRL) dieses Zertifikats abrufen können.
Zugriff auf Behördeninformationen (AIA)	Eine Zertifikatserweiterung, die die URL des OCSP-Responder- oder Ausstellerzertifikats der ausstellenden Zertifizierungsstelle enthält.
Zirkuläre Abhängigkeit (Unbegrenzte Rekursion)	Der in RFC 5280 beschriebene Validierungsfehler tritt auf, wenn das eigene HTTPS-Zertifikat eines Widerrufsendpunkts von derselben Widerrufsprüfung abhängt, die es beantworten soll.
Soft-Fail-Widerrufsprüfung	Ein Clientverhalten, das ein Zertifikat als gültig behandelt, wenn die Widerrufsprüfung nicht abgeschlossen werden kann, anstatt die Verbindung zu blockieren.
Prüfung auf sofortigen Widerruf	Ein Clientverhalten, das eine Verbindung blockiert, wenn der Widerrufsstatus eines Zertifikats nicht bestätigt werden kann.
Kurzzeitzertifikat	Bei einem Zertifikat mit einer so kurzen Gültigkeitsdauer, dass sie bei den aktuellen Abstimmungen des CA/Browser Forums nur 7 Tage beträgt, ist eine Überprüfung des Widerrufs in Echtzeit weitgehend überflüssig.
RFC 5280	Der IETF-Standard für X.509-Zertifikate und CRLs rät davon ab, Widerrufs-Endpunkte über HTTPS zu hosten, da dies das Risiko zirkulärer Abhängigkeiten birgt.

Fazit

In der PKI geht es bei Sicherheit nicht nur um Verschlüsselung; es geht darum, sicherzustellen, dass Daten signiert, vertrauenswürdig und zugänglich sind, ohne die Vertrauenskette zu unterbrechen. HTTPS hat seine Berechtigung, aber für den Zertifikatswiderruf ist HTTP oft zuverlässiger. Wir von Encryption Consulting entwickeln PKI- Systeme, die ein Gleichgewicht zwischen Standards und praktischer Leistung herstellen und Ihnen helfen, Fallstricke zu vermeiden, die die Verfügbarkeit oder Compliance beeinträchtigen könnten.

Sie möchten eine zukunftssichere PKI aufbauen? Kontaktieren Sie unsere PKI-Experten unter [email protected] oder besuchen Sie https://www.encryptionconsulting.com, um zu erfahren, wie wir Sie unterstützen können.

Häufig gestellte Fragen

Warum ist HTTP für CRL- und OCSP-Endpunkte oft besser als HTTPS?

CRLs und OCSP-Antworten sind bereits digital von der ausstellenden Zertifizierungsstelle signiert. HTTPS fügt zwar Transportverschlüsselung hinzu, bietet aber keine zusätzliche Vertrauenswürdigkeit oder Manipulationssicherheit. Die Bereitstellung über HTTPS kann zudem die in RFC 5280 beschriebene zirkuläre Abhängigkeit erzeugen, bei der die Validierung der HTTPS-Verbindung dieselbe Widerrufsprüfung erfordert, die der Endpunkt eigentlich beantworten soll.

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

Ein falsch konfigurierter Widerrufsendpunkt betrifft nicht nur ein einzelnes Zertifikat, sondern kann kaskadierend zu TLS-Handshake-Fehlern bei allen Diensten führen, die darauf angewiesen sind. Dies zeigte sich in realen Implementierungen, bei denen HTTPS-gehostete CRLs und OCSP-Responder Validierungsfehler unter strengen bundesstaatlichen Compliance-Vorgaben verursachten.

Was passiert, wenn eine zirkuläre Abhängigkeit bei der Widerrufsprüfung unbemerkt bleibt?

Wenn vertrauende Parteien versuchen, das HTTPS-Zertifikat am Widerrufsendpunkt selbst zu validieren, entsteht eine ungebundene Rekursionsschleife, vor der RFC 5280 ausdrücklich warnt. Dies kann Vertrauensketten unterbrechen und Dienste stören, manchmal sogar über Firewalls und abhängige Systeme hinaus, weit über das ursprüngliche Zertifikat hinaus.

Welches Team sollte für die Konfiguration und Überwachung des Widerrufsendpunkts zuständig sein?

Die PKI oder die Sicherheitstechnik ist typischerweise für das Design und Hosting von CDP- und AIA-Endpunkten zuständig, während der IT-Betrieb oder eine Zertifikatslebenszyklus-Management-Plattform die laufende Überwachung der Aktualität der CRL, der Verfügbarkeit des OCSP-Responders und der Gültigkeit der Signatur übernehmen sollte.

Wie hängt die Gestaltung von Widerrufsendpunkten mit dem Zertifikatslebenszyklusmanagement (CLM) zusammen?

Eine CLM-Plattform wie CertSecure Manager automatisiert die Veröffentlichungspläne für CRLs, überwacht den Zustand der OCSP-Responder und kann Widerrufsprüfungen in CI/CD- und Zero-Trust-Pipelines integrieren. Dadurch entfällt das manuelle Rätselraten, das zu veralteten CRLs oder unbemerkten Responder-Ausfällen führen kann.

Wie lässt sich messen, ob die Bereitstellung eines Widerrufsendpunkts ordnungsgemäß funktioniert?

Bestätigen Sie, dass CRLs rechtzeitig vor dem nächsten Aktualisierungsdatum neu veröffentlicht werden, OCSP-Mitarbeiter innerhalb einer akzeptablen Latenzzeit ohne ungeplante Ausfälle antworten und ein absichtlich widerrufenes Testzertifikat sowohl durch CRL- als auch durch OCSP-Prüfungen korrekt als widerrufen gemeldet wird.

Was sollte in der CRL- und OCSP-Infrastruktur regelmäßig überwacht werden?

Überwachen Sie regelmäßig das Ablaufdatum des CRL nextUpdate, die Verfügbarkeit und Latenz des OCSP-Responders, die korrekten CA-Signaturen bei jeder Antwort und ob die vertrauenden Parteien für Soft-Fail- oder Hard-Fail-Verhalten konfiguriert sind, da Soft-Fail Ausfälle des Responders stillschweigend verschleiert.

Wie ändert sich diese Richtlinie in Cloud- oder Multi-CA-Umgebungen?

Cloud-native Zertifizierungsstellen wie AWS Private CA oder Azure Key Vault, neben Microsoft ADCS oder Open-Source-Zertifizierungsstellen wie EJBCA, können jeweils unterschiedliche OCSP- und CRL-Richtlinien festlegen, da OCSP durch Ballot SC-063v4 optional wurde. Daher benötigen Umgebungen mit mehreren Zertifizierungsstellen eine einzige Überwachungsebene, die das tatsächliche Widerrufsverhalten jeder Zertifizierungsstelle berücksichtigt, anstatt von einer einheitlichen Unterstützung auszugehen.

Welche häufigen Fehler begehen Organisationen im Umgang mit CRL- und OCSP-Endpunkten?

Zu den häufigsten Fehlern gehören das Hosten von Widerrufsendpunkten über HTTPS ohne unabhängigen Validierungspfad, das Veraltenlassen von CRLs über das nextUpdate-Feld hinaus, das Verlassen auf Soft-Fail-Clients, als wären sie Hard-Fail-Clients, und das Versäumnis, den Widerruf vor der Inbetriebnahme mit einem tatsächlich widerrufenen Zertifikat zu testen.

Wie wirken sich kurzlebige Zertifikate und die jüngsten Abstimmungen des CA/Browser Forums auf die Widerrufsstrategie aus?

Der stufenweise Zeitplan von Wahlzettel SC-081v3 hin zu einer 47-tägigen Zertifikatsgültigkeit bis März 2029 sowie kurzlebigen Zertifikatsprofilen von nur 7 Tagen verringert, inwieweit Organisationen überhaupt auf Live-Widerrufsprüfungen angewiesen sind, da ein Zertifikat, das schnell abläuft, das Schadensfenster eines kompromittierten Schlüssels mit oder ohne erfolgreiche CRL- oder OCSP-Prüfung begrenzt.