What is OCSP (Online Certificate Status Protocol)?

OCSP meaning

OCSP stands for Online Certificate Status Protocol. The word status is the point: the response says one of three things. Good means the certificate has not been revoked. Revoked means it has. Unknown means the responder does not recognise it. The responder signs its reply so the answer cannot be altered in transit.

How OCSP works

The address of the responder is stored in the certificate, in the authority information access extension of its X.509 format. The process is:

• The software reads the responder address from the certificate.
• It sends a request with the issuer details and the certificate serial number.
• The responder looks up the status and returns a signed response with a time it was produced.
• The software checks the signature and the time, then accepts or rejects the certificate.

OCSP stapling

Asking the authority each time adds delay and tells the authority which certificates are being checked. Stapling solves both. The certificate holder, or the server, fetches a recent OCSP response and attaches it. The verifier trusts the signed response and does not contact the authority. In signed PDFs, the same idea is used when the response is embedded in the file for long-term validation.

OCSP vs CRL

OCSP answers are small and current. Lists are larger and may be stale but work offline. The weak point of OCSP is availability: if the responder is down, software must decide whether to fail or to carry on. Strict systems fail. Keeping the answer inside the signed document avoids the problem.

What happens when the responder is down

Because OCSP needs a live server, the checker has to decide what to do when no answer comes. Failing closed means the certificate is rejected, which is safe but can stop real work. Failing open means it is accepted, which keeps work moving but lets a revoked certificate through. Signed documents avoid the dilemma when the answer was captured at signing time.

Responses carry a produced-at time and a next-update time, and checkers should reject answers that are too old. A nonce can tie an answer to one request, though many responders skip it for speed and sign pre-produced answers instead. These details are why a signed PDF that embeds its own answers, as in PAdES, is easier to trust years later.

Example: checking a signature in a PDF reader

When you open a signed HR letter, the reader builds the chain and sends one OCSP request for the signer’s certificate. A second request may go for the intermediate. Each reply is signed by the authority’s responder. The reader then shows a green status if all are good.

On a slow connection the request can time out, and the reader may show the signature as valid with a warning that revocation could not be checked. That is the reader being honest: the signature is fine mathematically, but one fact is unconfirmed. Try again online, or ask the sender for a copy with the answers embedded.

Privacy and scale

Each OCSP request tells the responder which certificate is being checked and, from the network address, who is checking. For signature checks by a bank, that can reveal which customers are being served. Stapling and embedded answers remove this leak because the verifier does not contact the authority.

Responders also face load: a popular certificate can be checked millions of times. Authorities handle this with pre-signed answers valid for a few days, which are cached and served by many servers. That is why an OCSP answer carries a validity window and should not be treated as a live feed.