Cybersecurity glossary
What is Certificate Revocation (CRL/OCSP)?
Learn what certificate revocation is, how CRLs and OCSP tell clients a certificate is no longer trusted, the tradeoffs of each method, and how short-lived certificates change the model.
Definition
Certificate revocation is the process of invalidating an issued X.509 certificate before its expiration date, commonly communicated to relying parties through Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP).
Why certificate revocation matters
A certificate is a time-bound voucher of trust. Sometimes that voucher must be canceled early. A laptop is stolen. A web server private key leaks. A certificate was issued to the wrong subscriber. Waiting months for natural expiry is unacceptable.
Certificate revocation is the PKI control that communicates “stop trusting this serial now.” The two classic distribution mechanisms are CRLs and OCSP. Neither is magic. Both depend on CA availability, client behavior, caching, and operational discipline.
How revocation fits the trust decision
When a client validates a certificate, expiry and chain trust are not enough. If the certificate was revoked, acceptance is a security failure—unless the deployment consciously relies on lifetimes so short that revocation windows are tiny.
Detect a revoke-worthy event
Key compromise, mis-issuance, identity change, device loss, or policy violation triggers action.
CA marks the serial revoked
The issuer records the certificate serial and revocation reason in its status systems.
Publish status
Updated CRLs and OCSP responses become available to relying parties.
Clients obtain status
Direct OCSP queries, stapled responses, CRL fetches, or proprietary status pushes deliver the information.
Enforce rejection
Validators refuse the certificate for new handshakes and sessions according to policy.
Replace credentials
Operators re-issue clean certificates and restore service without reintroducing the compromised key.
CRL vs OCSP
| Property | CRL | OCSP |
|---|---|---|
| What is fetched | A list of many revoked serials | Status for one certificate (typically) |
| Caching behavior | Clients cache whole lists for a validity interval | Responses are cached per certificate with their own TTL |
| Privacy | Download does not reveal which site you visit | Direct queries can reveal browsing to the responder |
| Size / scale | Can grow large for busy CAs | Small responses, but high query volume |
| Common enhancement | Partitioned CRLs and efficient delta mechanisms | OCSP stapling by the TLS server |
OCSP stapling and privacy
With stapling, the server periodically obtains a signed OCSP response and presents it during TLS. Clients verify the staple instead of contacting the CA. That reduces client-to-CA leakage and can improve handshake reliability when responders are otherwise flaky.
Stapling only helps when servers are configured to staple correctly and clients enforce status where policy requires it. A missing staple with soft-fail behavior can recreate the old “revocation is optional” problem.
Soft-fail versus hard-fail
Hard-fail
If status cannot be obtained, the certificate is not accepted. Stronger security, higher outage risk when responders fail.
Soft-fail
If status cannot be obtained, validation may continue. Better availability, weaker compromise response.
Short-lived certs
Minutes-to-days lifetimes shrink the window where missing revocation data matters.
Private PKI push
Enterprise agents can push revocation or remove local certs faster than public web PKI allows.
Browser ecosystems have historically struggled with ubiquitous hard-fail on the public web. Enterprise mTLS and high-assurance systems can choose stricter policies because the client set is controlled.
Operational checklist
- Document revoke triggers and on-call ownership for TLS, client, and code-signing certificates.
- Test that revoked certificates are actually rejected by your clients, gateways, and libraries.
- Enable OCSP stapling on public TLS terminators where supported and monitor staple freshness.
- Keep CRL/OCSP endpoints highly available and independently monitored from the issuing service.
- Prefer short-lived automated certificates for workloads to reduce emergency revocation pressure.
- Never reuse a private key after a suspected compromise; revoke and re-key.
- Track cached status lifetimes so you understand how long a revoke may take to become effective.
- For private client auth, combine revocation with inventory-driven disablement of lost devices.
Common failures
Organizations revoke in a portal and assume the internet instantly complies. In reality, caches delay enforcement. Others disable revocation checks after an outage and never re-enable them. Private PKIs sometimes publish CRLs on unreachable internal URLs, so clients soft-fail forever.
Another subtle issue is reason codes and policy: stolen devices, superseded certificates, and privilege removal all need playbooks, not only a checkbox labeled “revoke.”
The practical takeaway
Certificate revocation (CRL/OCSP) is how PKI communicates early invalidation of issued certificates. CRLs distribute lists; OCSP answers targeted status queries; stapling improves delivery on TLS servers.
Revocation is only as strong as publication speed, client enforcement, and certificate lifetime strategy. Design for compromise before you need it: monitor status infrastructure, practice re-issue drills, and use short-lived credentials where they fit.
Related security terms
Certificate Authority (CA)
The issuer responsible for publishing authoritative revocation status for certificates it signed.
X.509 Certificate
The credential whose serial number appears on CRLs or in OCSP responses when revoked.
Public Key Infrastructure (PKI)
The broader trust framework that depends on timely status information.
Certificate Transparency
complementary ecosystem control for detecting unexpected public TLS issuance.
Frequently asked questions
What is certificate revocation in simple terms?
Revocation is how a Certificate Authority says a certificate should no longer be trusted, even though its expiry date has not arrived yet. Clients learn that status through CRLs, OCSP, or by using certificates so short-lived that revocation is less critical.
What is a CRL?
A Certificate Revocation List is a signed list of revoked certificate serial numbers published by a CA. Clients download and cache the list, then reject certificates whose serials appear as revoked.
What is OCSP?
The Online Certificate Status Protocol lets a client query a responder for the current status of a specific certificate serial, typically receiving a signed good, revoked, or unknown response.
What is OCSP stapling?
OCSP stapling is when a TLS server fetches an OCSP response and sends it to clients during the handshake. Clients can check status without contacting the CA directly, improving privacy and often performance.
Why do some clients soft-fail revocation checks?
If a revocation service is unreachable, hard-failing can break browsing or APIs. Some clients soft-fail for availability, which weakens revocation guarantees. Short-lived certificates reduce dependence on perfect revocation reachability.
When should a certificate be revoked?
Revoke when a private key may be compromised, a certificate was mis-issued, a device is retired, an employee leaves, names are no longer valid, or policy requires immediate invalidation before expiry.
Do short-lived certificates eliminate the need for revocation?
They reduce urgency because stolen credentials expire quickly, but operators still need emergency revocation for longer-lived certificates and for policy violations discovered mid-lifetime.
References
Explore authoritative guidance and frameworks related to certificate revocation (crl/ocsp).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.