What is OCSP (Online Certificate Status Protocol)

OCSP (Online Certificate Status Protocol), defined in RFC 6960, allows a client to query a CA’s OCSP responder to check whether a specific certificate has been revoked. Instead of downloading an entire Certificate Revocation List (CRL) containing thousands of entries, the client sends a request with the certificate’s serial number and receives a signed response: “good” (not revoked), “revoked” (with reason and date), or “unknown” (responder doesn’t know this certificate).

Why it matters

• Real-time revocation — CRLs are published periodically (hours to days). OCSP can reflect revocation within minutes of the CA processing it. Critical when a private key is actively being exploited.
• Bandwidth efficiency — a CRL for a large CA can be megabytes. An OCSP response is ~1-2KB. For constrained clients (mobile, IoT), this difference matters.
• Per-certificate granularity — the client asks about one specific certificate. It doesn’t download revocation status for millions of certificates it doesn’t care about.
• Privacy concern — every OCSP query tells the CA (or responder operator) which sites the client is visiting. This is why OCSP stapling exists — to move the query to the server side.
• Soft-fail reality — most browsers treat OCSP responder unavailability as “certificate is fine” (soft-fail). This means an attacker who can block OCSP traffic can use a revoked certificate without detection.

How it works

1. Client receives certificate — during TLS handshake, client gets the server’s certificate containing an Authority Information Access (AIA) extension with the OCSP responder URL.
2. Client builds OCSP request — creates a request containing: issuer name hash, issuer key hash, and the certificate’s serial number.
3. Client sends request — HTTP POST (or GET with base64-encoded request) to the OCSP responder URL.
4. Responder checks status — looks up the certificate’s serial number in its database. Returns signed response.
5. Response received — contains: status (good/revoked/unknown), thisUpdate (when status was last confirmed), nextUpdate (when to check again), and the responder’s signature.
6. Client validates response — verifies the responder’s signature (must chain to the same CA or a delegated OCSP signing certificate), checks freshness (thisUpdate/nextUpdate), and acts on the status.

In real systems

OCSP stapling in Nginx (server-side, recommended):

server {
    listen 443 ssl;
    ssl_certificate     /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/certs/ca-chain.pem;  # For verifying OCSP response
    resolver 8.8.8.8 valid=300s;  # DNS resolver for OCSP responder lookup
    resolver_timeout 5s;
}

The server periodically fetches the OCSP response and “staples” it to the TLS handshake. Clients get revocation status without contacting the OCSP responder directly.

Checking OCSP status manually:

# Extract OCSP responder URL from certificate
openssl x509 -in cert.pem -noout -ocsp_uri
# Output: http://ocsp.letsencrypt.org

# Query OCSP responder
openssl ocsp \
  -issuer intermediate.pem \
  -cert cert.pem \
  -url http://ocsp.letsencrypt.org \
  -resp_text

# Response includes:
# Cert Status: good
# This Update: Apr 28 00:00:00 2026 GMT
# Next Update: May  5 00:00:00 2026 GMT

OCSP Must-Staple (certificate extension):

# Request a certificate with OCSP Must-Staple
openssl req -new -key server.key -out server.csr \
  -addext "tlsfeature = status_request"

When a certificate includes the Must-Staple extension (TLS Feature 1.3.6.1.5.5.7.1.24), the client MUST receive a stapled OCSP response during the handshake. If the server doesn’t staple, the client rejects the connection — converting soft-fail to hard-fail.

Where it breaks

Soft-fail defeats the purpose — Chrome, Firefox, and Safari all soft-fail on OCSP by default. If the OCSP responder is unreachable (network issue, responder down, or attacker blocking traffic), the browser accepts the certificate as valid. An attacker with a revoked certificate simply blocks OCSP traffic and the revoked cert works fine. This is why Google has called OCSP “privacy-violating and ineffective” and Chrome doesn’t check OCSP at all (using CRLSets instead).

OCSP responder as availability dependency — if the CA’s OCSP responder goes down, every client checking revocation for that CA’s certificates experiences delays (timeout waiting for response) or failures (if hard-fail is configured). Let’s Encrypt’s OCSP responder handles billions of queries — an outage affects a significant portion of the internet. This is why stapling is critical: it decouples client experience from responder availability.

Stapling not configured or stale — the server is configured for OCSP stapling, but the stapled response expires (nextUpdate passes) and the server can’t reach the OCSP responder to refresh it (DNS issue, firewall rule, responder down). The server continues serving the stale/missing staple. Clients with Must-Staple certificates reject the connection. Clients without Must-Staple fall back to direct OCSP query (adding latency) or soft-fail. Monitor stapling freshness, not just certificate expiry.

Operational insight

OCSP is in a slow decline. Chrome doesn’t use it (relies on CRLSets/CRLite — compressed revocation data pushed to browsers). Firefox is moving toward CRLite. Safari still checks OCSP but soft-fails. The practical implication: for public web certificates, OCSP revocation is unreliable as a security control. The industry is converging on two alternatives: short-lived certificates (90 days or less, where revocation is less critical because the certificate expires quickly anyway) and CRLite (browser-side compressed revocation database updated every few hours). For private/enterprise PKI, OCSP still works because you control both the responder and the clients — you can enforce hard-fail and guarantee responder availability.

Related topics

• What is CRL
• Certificate Renewal and Revocation
• What is a TLS Certificate
• What is Certificate Transparency
• Certificate Validity and 90-Day Proposals