How it works
OCSP (RFC 6960) works as a lookup: the client sends a certificate’s serial number to the issuing CA’s OCSP responder and gets back a signed answer – “good”, “revoked” or “unknown”. The responder’s URL is embedded in the certificate itself, in the Authority Information Access extension.
Because every lookup reveals which site someone is visiting and adds latency, OCSP stapling was introduced: the web server fetches the signed response itself at regular intervals and includes it in the TLS handshake. The response is signed by the CA and valid for only a few days, so the server cannot forge it.
OCSP is fading out. A 2023 CA/Browser Forum ballot made it optional for public CAs while CRLs became mandatory. Let’s Encrypt shut down its OCSP responders in 2025, and browsers mostly check revocation through their own pre-distributed lists (CRLSets in Chrome, CRLite in Firefox) rather than live queries.
Why it matters
Revocation only helps if clients notice it. If a server’s private key is stolen, an attacker can impersonate the real site with that certificate until it expires whenever clients skip the status check or silently ignore a failed lookup (soft-fail), which is what most browsers do.
OCSP can also cause outages of its own: Firefox rejects a certificate carrying the “OCSP Must-Staple” extension when the server fails to staple a valid response – for example because the responder was unreachable or the cached response expired.
How to prevent it
- If a key leaks or a certificate was misissued, have it revoked by the CA right away (with Let’s Encrypt, for example, via certbot revoke) and issue a new one with a fresh key.
- Where the CA still offers OCSP, turn on stapling on the web server (nginx: ssl_stapling on and ssl_stapling_verify on; Apache: SSLUseStapling On) and allow the server to reach the responder.
- Only use Must-Staple if your server staples reliably; Let’s Encrypt no longer issues such certificates anyway.
- Prefer short lifetimes: the shorter a certificate is valid, the smaller the window in which a stolen key is useful without effective revocation.
- Keep private keys only on the servers that need them, and replace certificates and keys after a service provider leaves.
How DomainWarn detects it
DomainWarn does not check this directly: the Certificate check does not query OCSP responders, does not evaluate stapled OCSP responses and does not download revocation lists. A revoked certificate that is otherwise valid is therefore not reported as revoked.
The Certificate issuance check helps indirectly: it reports every newly issued certificate and every previously unseen certificate authority from the CT logs, so an unwanted certificate stands out and you can have it revoked. The Certificate check also logs every renewal as an event, which shows whether the replacement certificate is actually being served after a revocation.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.