Online Certificate Status Protocol – Wikipedia

Das Online Certificate Status Protocol (OCSP) ist ein Netzwerkprotokoll, das es Clients ermöglicht, den Status von X.509-Zertifikaten bei einem Validierungsdienst abzufragen. Es ist im RFC 6960 beschrieben und ein Internetstandard.

Benötigt wird dies z. B. bei:

• der Prüfung digitaler Signaturen
• der Authentisierung in Kommunikationsprotokollen (z. B. bei TLS)
• der Verschlüsselung von E-Mails,

um jeweils zu überprüfen, ob die verwendeten Zertifikate evtl. gesperrt und damit bereits vor Ende ihres regulären Gültigkeitszeitraums ungültig wurden.

Mittels OCSP kann der Status eines Zertifikats durch Anfrage bei einem Server (ein so genannter OCSP-Responder) abgefragt werden. Dieser OCSP-Responder wird in der Regel vom Herausgeber des Zertifikats betrieben und liefert als Antwort „good“ (d. h. das Zertifikat ist nicht gesperrt), „revoked“ (Zertifikat ist gesperrt) oder „unknown“ (der Status konnte nicht ermittelt werden, etwa weil der Herausgeber des Zertifikats dem Responder nicht bekannt ist). Des Weiteren besteht die Möglichkeit, dass der OCSP-Responder sogenannte Positivauskünfte („Zertifikat ist authentisch und gültig“) erteilt. Dabei wird der Antwort ein Hash-Wert des Zertifikats mitgegeben, wenn das Zertifikat tatsächlich existiert. Die Erteilung von Positivauskünften ist im OCSP-Standard RFC 2560^[1] allerdings nicht vorgesehen, so dass ihre korrekte Auswertung ein vom Standard abweichendes Verhalten der OCSP-Clients erfordert. In Deutschland ist die Erteilung von Positivauskünften für qualifizierte Zertifikate vom Signaturgesetz gefordert.

Reguläre Antworten (OCSP Response) sind stets vom OCSP Responder digital signiert und können somit vom Client auf ihre Echtheit und Unverfälschtheit geprüft werden. Antworten, die Fehlersituationen repräsentieren, sind nicht signiert. Die Anfrage (OCSP Request) kann signiert sein, muss es aber nicht sein; in der Praxis werden OCSP Requests selten signiert.

OCSP erlaubt es auch, in einer Anfrage die Gültigkeit mehrerer Zertifikate abzufragen; der Responder liefert dann in seiner Antwort eine Liste mit den jeweiligen Zertifikatsstatus.

Sofern ein OCSP-Responder auf einer aktuellen Datenbasis (z. B. einer Replikation der Datenbank der Zertifizierungsstelle) arbeitet, gibt er stets den gegenwärtigen Sperrstatus des Zertifikates an. Für die Gültigkeit einer elektronischen Signatur ist aber unter Umständen nicht der Status des Zertifikates zum Zeitpunkt der Prüfung (und der OCSP-Abfrage) relevant, sondern der Status zum (vergangenen) Zeitpunkt der Signierung (dies gilt z. B. für elektronische Signaturen nach dem deutschen Signaturgesetz). Daher müssen die OCSP-Antworten bei einem gesperrten Zertifikat auch den Sperrzeitpunkt angeben, so dass sich daraus ermitteln lässt, ob dieses Zertifikat zu einem bestimmten Zeitpunkt noch gültig war. Falls jedoch die Zertifizierungsstelle vorübergehende Sperrungen (Suspendierungen) zulässt, kann man einer positiven OCSP-Antwort („good“) nicht entnehmen, ob dieses Zertifikat zwischenzeitlich suspendiert war. Allerdings wird dies gemeinhin nicht als Nachteil von OCSP gewertet, sondern vielmehr die Suspendierung von Signaturzertifikaten als problematisch für elektronische Signaturen angesehen. Daher ist eine solche Suspendierung in Deutschland für qualifizierte Zertifikate nicht zugelassen. Im Unterschied zu OCSP unterstützt das Server-based Certificate Validation Protocol die Abfrage des Zertifikatsstatus zu einem vergangenen Zeitpunkt.

OCSP besitzt kein eigenes Transport-Protokoll, zum Transport wird in der Regel http oder https verwendet.

OCSP wird inzwischen von vielen Standard-Programmen und Betriebssystemen (z. B. Microsoft Windows Vista, Adobe Acrobat, Mozilla Firefox, Mozilla Thunderbird, Lotus Notes Version 8, Opera ab Version 8^[2][3]) unterstützt. Einige, vor allem ältere Programme unterstützen nur Zertifikatsperrlisten (CRLs) zur Prüfung des Zertifikatsstatus.

Um der Forderung des Signaturgesetzes nach einem aktuellen Auskunftsdienst zu genügen, betreiben alle Aussteller von qualifizierten Zertifikaten in Deutschland einen OCSP-Responder.

Im Gegensatz zu Sperrlisten, die nur in bestimmten Intervallen erstellt werden und damit nicht immer aktuell sind, können OCSP-Responder sekundengenaue Sperrinformationen liefern, sofern sie eine aktuelle Datenbasis verwenden (z. B. die CA-Datenbank).

Außerdem ermöglicht es OCSP im Gegensatz zu Sperrlisten, nicht gesperrte Zertifikate von gefälschten Zertifikaten zu unterscheiden – wenn der OCSP-Responder so konfiguriert ist, dass er nur bei tatsächlich existierenden Zertifikaten die Antwort „good“ liefert (Positivauskunft). Dies wird vor allem dann wichtig, wenn die von der Zertifizierungsstelle (CA) zur Signierung der Zertifikate eingesetzten Algorithmen und Schlüssellängen im Laufe der Zeit unsicher und Fälschungen möglich werden. Allerdings sieht der Standard vor, dass ein OCSP-Responder bereits dann die Antwort „good“ liefert, wenn das Zertifikat nicht in einer Sperrliste gelistet ist; in diesem Fall könnte das Zertifikat auch gar nicht ausgestellt worden, d. h. gefälscht sein.

OCSP liefert – wie Sperrlisten – nur Auskünfte zum Sperrstatus von Zertifikaten, prüft aber nicht die mathematische Korrektheit der Signaturen der Zertifikate, ihre Gültigkeitsdauer oder ggf. im Zertifikat angegebene Nutzungsbeschränkungen. Außerdem muss der Client zunächst eine Zertifizierungskette ermitteln. Um diese Aufgaben an den Auskunftsdienst auszulagern, wurde SCVP entwickelt.

Weiterhin hängt die Aktualität von OCSP-Antworten von der verwendeten Datenbasis ab. Bei manchen Implementierungen basiert der OCSP-Responder auf einer Sperrliste und liefert daher keine aktuelleren Sperrinformationen als diese.

Problematisch ist, dass viele Client-Implementierungen ein Zertifikat auch dann als gültig betrachten, wenn sie die Fehlerantwort „tryLater“ erhalten. Da Fehlerantworten nicht signiert sind, kann ein Angreifer durch gefälschte „tryLater“-Antworten die OCSP-Prüfung aushebeln.^[4]

Die ursprüngliche OCSP-Implementierung kann zu beträchtlichen Kosten für die Zertifizierungsstellen führen, da diese dabei für ein bestimmtes Zertifikat jedem Client in Echtzeit Antworten liefern müssen. Wenn beispielsweise eine Website mit hohem Verkehrsaufkommen ein Zertifikat ausgestellt bekommt, dann werden die Server der Zertifizierungsstelle wahrscheinlich von einem starken Aufkommen an OCSP-Anfragen getroffen, die die Gültigkeit des Zertifikates abfragen.

Die Verwendung von OCSP wirft Fragen hinsichtlich der Wahrung der Privatsphäre auf, weil es bedingt, dass der Client neben dem eigentlichen Kommunikationsziel eine dritte Partei kontaktiert, um die Gültigkeit des Zertifikats zu überprüfen. Eine Möglichkeit, dieses Problem zu lösen, liegt in der Verwendung von OCSP Stapling, dabei wird z. B. das Browserverhalten nicht enthüllt.

• Certificate Validation Service

Nachfolgend der Entwicklungspfad zum aktuellen Request for Comments (RFC):

• RFC 2560 – X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP. Juni 1999 (veraltet, englisch).
  • RFC 6277 – Online Certificate Status Protocol Algorithm Agility. Juni 2011 (Ergänzung, veraltet, englisch).
• RFC 6960 – X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP. Juni 2013 (englisch).

1. ↑ RFC 2560 – X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP. Juni 1999 (veraltet, englisch).
2. ↑ Yngve Nysæter Pettersen: Introducing Extended Validation Certificates. Opera Software, 9. November 2006, archiviert vom Original (nicht mehr online verfügbar) am 10. Februar 2010; abgerufen am 8. Januar 2010 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/labs.opera.com 
3. ↑ Yngve Nysæter Pettersen: Rootstore newsletter. Opera Software, 3. Juli 2008, archiviert vom Original (nicht mehr online verfügbar) am 18. November 2008; abgerufen am 8. Januar 2010 (englisch). 
4. ↑ Moxie Marlinspike: Defeating OCSP. (PDF; 64 kB) Abgerufen am 27. Januar 2011 (englisch).