Dieses Projekt ist eine private, nicht-offizielle Zusammenstellung. Die Inhalte wurden mit Hilfe von KI auf Basis öffentlich zugänglicher Quellen (fachportal.gematik.de, gematik.de) erstellt. Keine Verbindung zur gematik GmbH. Fehler möglich. Beiträge willkommen.
Protokoll zur Echtzeit-Abfrage des Sperrstatus eines X.509-Zertifikats direkt beim Aussteller, definiert in RFC 6960.
Erklärt für Einsteiger
Wenn du einer Person vertraust, weil sie dir einen Ausweis zeigt, möchtest du manchmal sicherstellen, dass dieser Ausweis nicht gesperrt wurde. OCSP macht genau das für digitale Zertifikate: Es fragt beim Aussteller an, ob ein bestimmtes Zertifikat noch gültig ist. Das ist schneller als das Durchsuchen einer langen Liste gesperrter Ausweise.
Überblick
OCSP (Online Certificate Status Protocol) ist ein Protokoll aus der Infrastruktur für öffentliche Schlüssel (PKI). Es ermöglicht einem Client, den aktuellen Sperrstatus eines X.509-Zertifikats bei einer Zertifizierungsstelle oder einem beauftragten OCSP-Responder abzufragen. Der Standard ist in RFC 6960 spezifiziert und ersetzt in vielen Szenarien die älteren Certificate Revocation Lists (CRL).
In der Telematikinfrastruktur (TI) ist OCSP ein zentraler Mechanismus zur Zertifikatsprüfung. Konnektoren prüfen bei jeder Kommunikation die Gültigkeit von Zertifikaten auf eGK, HBA und SMC-B über OCSP-Anfragen an die TSP-Responder. Die gematik-Spezifikation gemKPT_PKI_TIP beschreibt OCSP als Standardprotokoll für den Zertifikatsstatus und definiert Optimierungsoptionen für die TI-Architektur.
Interesse technik
OCSP-Responder-URL: Im Zertifikat im Feld AuthorityInfoAccess (OID 1.3.6.1.5.5.7.48.1). Anfrage per HTTP GET (bis 255 Byte) oder POST. Request/Response in DER-kodiertem ASN.1. Content-Type: application/ocsp-request / application/ocsp-response. In der TI werden OCSP-Antworten gecacht (Gültigkeitsdauer laut nextUpdate-Feld). gematik-Referenzimplementierung: github.com/gematik/ref-GemLibPki. ECC-Migration: Ab 1. Januar 2026 müssen neue TI-Zertifikate ECC-256 nutzen; OCSP-Prüfung unterstützt beide Algorithmen in der Übergangszeit.
Der Vorteil von OCSP gegenüber CRL liegt in der Aktualität: CRLs müssen heruntergeladen und lokal gecacht werden und können veraltet sein. OCSP liefert eine Echtzeitauskunft direkt für das angefragte Zertifikat.
Technische Details
Ablauf einer OCSP-Abfrage
Der Client erstellt einen OCSPRequest mit der Identifikation des zu prüfenden Zertifikats.
Der Request wird per HTTP GET oder POST an den OCSP-Responder gesendet. Die Responder-URL steht im Zertifikat selbst im Feld AuthorityInfoAccess.
Der OCSP-Responder antwortet mit einem signierten OCSPResponse.
Nachrichtenformat
Nachrichten werden in ASN.1 kodiert und über HTTP transportiert. Der Content-Type bei POST-Anfragen lautet application/ocsp-request, Antworten verwenden application/ocsp-response.
OCSPRequest: Enthält ein oder mehrere CertID-Objekte mit:
hashAlgorithm: verwendeter Hash-Algorithmus (typisch SHA-1 oder SHA-256)
issuerNameHash: Hash des Distinguished Name der ausstellenden CA
issuerKeyHash: Hash des öffentlichen Schlüssels der ausstellenden CA
serialNumber: Seriennummer des zu prüfenden Zertifikats
OCSPResponse: Enthält pro Zertifikat einen SingleResponse mit dem Status:
good: Zertifikat ist gültig und nicht gesperrt
revoked: Zertifikat wurde gesperrt, mit optionalem Sperrzeitpunkt und Sperrgrund
unknown: Der Responder hat keine Information über dieses Zertifikat
Bei Anfragen unter 255 Byte kann GET verwendet werden: GET {url}/{base64-encoded DER OCSPRequest}. Größere Anfragen verwenden POST mit dem DER-kodierten Request im Body.
Nonce-Extension
Um Replay-Angriffe zu verhindern, kann der Client eine Nonce in den Request einfügen. Ein Angreifer kann eine gespeicherte “good”-Antwort nicht wiederverwenden, wenn die Nonce vom Responder in die Antwort eingebettet wird. Viele öffentliche Responder unterstützen Nonces nicht, da sie vorab signierte Antworten mit einer Gültigkeitsdauer von mehreren Tagen verwenden.
OCSP Stapling
OCSP Stapling (RFC 5019 / TLS Certificate Status Request, RFC 6066) ist eine Optimierung: Der TLS-Server lädt die OCSP-Antwort selbst vorab herunter und liefert sie beim TLS-Handshake mit. Der Client muss keinen separaten OCSP-Request stellen. Das reduziert Latenz und schützt die Privatsphäre, da der Client nicht direkt beim Responder anfragen muss.
OCSP in der Telematikinfrastruktur
Die TI-PKI verwendet eine Trust Service List (TSL), in der alle akkreditierten TSP-X.509-CAs eingetragen sind. Jedes Zertifikat enthält die OCSP-Responder-URL des ausstellenden TSP. Konnektoren prüfen Zertifikate von eGK, HBA und SMC-B über diese Responder. Das gematik-Referenzprojekt ref-GemLibPki implementiert die OCSP-Abfragen gemäß gematik-Spezifikation. Laut gemKPT_PKI_TIP ist neben OCSP auch CRL als Fallback-Mechanismus vorgesehen.
Kryptografische Anforderungen
Clients müssen RSA mit SHA-256 unterstützen. Die TI-Spezifikationen schreiben zudem ECC-Algorithmen vor, da die TI schrittweise von RSA auf ECC umgestellt wird.
Dev Quickstart: OCSP-Status per curl abfragen
OCSP-Responder-URL steht im Zertifikat im Feld AuthorityInfoAccess. Kleine Anfragen (unter 255 Byte) können per GET gestellt werden.