OCSP and certificate revocation: how browsers check a cert is still valid

A certificate has an expiry date, but sometimes it needs to be killed early: the private key leaks, a domain changes hands, or a cert was issued in error. Revocation is how a CA says "stop trusting this one," and the systems that deliver that message are worth understanding.

Two ways to publish revocation

• CRL (Certificate Revocation List). The CA publishes a signed list of every serial number it has revoked. Clients download the list and check whether a certificate is on it. The lists grow large, so this is slow and increasingly impractical.
• OCSP (Online Certificate Status Protocol). Instead of downloading a whole list, the client asks the CA about one specific certificate: "is serial number X still good?" The CA replies good, revoked, or unknown. It is targeted and fast, but it means the client contacts the CA on connections, which is both a performance and a privacy cost.

The privacy problem, and stapling

Classic OCSP leaks information: every time you visit a site, your browser may tell the site's CA which site you are visiting. OCSP stapling fixes this. The web server itself periodically asks the CA for a signed, time-stamped status for its own certificate, then "staples" that proof to the TLS handshake. The visitor gets the revocation proof without ever contacting the CA, and the handshake is faster.

This is why enabling stapling on your server (a one-line directive on most web servers) is a small but real win for both speed and user privacy.

Checking a certificate

If you suspect a certificate was revoked, or you want to confirm your own was not, you query its OCSP responder, whose URL is embedded in the certificate's Authority Information Access field. The OCSP Checker does this lookup for you and reports the status. To see the AIA URL and other fields inside a certificate, use the how to read an SSL certificate guide.