Quiz Entry - updated: 2026.10.20
How does the Online Certificate Status Protocol (OCSP) work, and how does it compare with a CRL?
The verifier sends the certificate's serial number to the CA's OCSP responder and gets back a signed answer, good, revoked or unknown, for that one certificate.
- The verifier (here the Apache web server) reads the responder URL from the certificate's AIA extension, or uses one it is configured with.
- It sends a request naming the certificate (issuer hash + serial number), optionally with a nonce.
- The responder looks up the CA's revocation data and returns good, revoked (with time and reason) or unknown, signed with an OCSP signing certificate that the CA issued to the responder.
- The verifier checks that signature and acts on the status.
* CRL ships the list; OCSP answers one question. *
| CRL | OCSP | |
|---|---|---|
| What is transferred | The whole list of revoked certificates | One status for one certificate |
| Freshness | As old as the last publication | As fresh as the responder's data (it may itself be fed from CRLs) |
| Client effort | Download and search the list | One small request |
| Works offline | Yes, with a cached list | No: needs the responder reachable |
| Privacy | CA sees nothing | Responder learns which certificate (site) is checked |
The "client asks server" model is exactly what the CKTECK lab builds: Apache asks the Windows Online Responder about each user certificate.
Go deeper:
Wikipedia: Online Certificate Status Protocol — protocol flow, comparison with CRLs and the privacy criticism.- RFC 6960: OCSP — the request/response format and status values.