Online Certificate Status Protocol

It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI).

In this case, the responder's certificate (the one that is used to sign the response) must be issued by the issuer of the certificate in question, and must include a certain extension that marks it as an OCSP signing authority (more precisely, an extended key usage extension with the OID {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)}) OCSP checking creates a privacy concern for some users, since it requires the client to contact a third party (albeit a party trusted by the client software vendor) to confirm certificate validity.

[2] OCSP-based revocation is not an effective technique to mitigate against the compromise of an HTTPS server's private key.

[10] OCSP also remains a valid defense against situations where the attacker is not a "man-in-the-middle" (code-signing or certificates issued in error).

Some requesters may not be able to connect because their local network prohibits direct Internet access (a common practice for internal nodes in a data center).

Google disabled OCSP checks by default in 2012, citing latency and privacy issues[20] and instead uses their own update mechanism to send revoked certificates to the browser.

[21] Several open source and proprietary OCSP implementations exist, including fully featured servers and libraries for building custom applications.