What is Online Certificate Status Protocol?

What is the Online Certificate Status Protocol (OCSP)?

OCSP is an IETF standard that lets clients (browsers, apps, services) check whether an X.509 TLS certificate is valid, revoked, or unknown—in real time—without downloading large Certificate Revocation Lists (CRLs). Instead of pulling a massive list of revoked certificates, a client asks an OCSP responder a simple question: “Is certificate X still good?” The responder returns a signed “good / revoked / unknown” answer.

OCSP is a cornerstone of modern Public Key Infrastructure (PKI) and the HTTPS ecosystem, improving performance and revocation freshness versus legacy CRLs.

Why OCSP Exists (The Problem It Solves)

  • Revocation freshness: CRLs can be hours or days old; OCSP responses can be minutes old.
  • Bandwidth & latency: CRLs are bulky; OCSP answers are tiny.
  • Operational clarity: OCSP provides explicit status per certificate rather than shipping a giant list.

How OCSP Works (Step-by-Step)

1) The players

  • Client: Browser, mobile app, API client, or service.
  • Server: The site or API you’re connecting to (presents a cert).
  • OCSP Responder: Operated by the Certificate Authority (CA) or delegated responder that signs OCSP responses.

2) The basic flow (without stapling)

  1. Client receives the server’s certificate chain during TLS handshake.
  2. Client extracts the OCSP URL from the certificate’s Authority Information Access (AIA) extension.
  3. Client builds an OCSP request containing the certificate’s serial number and issuer info.
  4. Client sends the request (usually HTTP/HTTPS) to the OCSP responder.
  5. Responder returns a digitally signed OCSP response: good, revoked, or unknown, plus validity (ThisUpdate/NextUpdate) and optional Nonces to prevent replay.
  6. Client verifies the responder’s signature and freshness window. If valid, it trusts the status.

3) OCSP Stapling (recommended)

To avoid per-client lookups:

  • The server (e.g., Nginx/Apache/CDN) periodically fetches a fresh OCSP response from the CA.
  • During the TLS handshake, the server staples (attaches) this response to the Certificate message using the TLS status_request extension.
  • The client validates the stapled response—no extra round trip to the CA, no privacy leak, and faster page loads.

4) Must-Staple (optional, stricter)

Some certificates include a “must-staple” extension indicating clients should require a valid stapled OCSP response. If missing/expired, the connection may be rejected. This boosts security but demands strong ops discipline (fresh stapling, good monitoring).

Core Features & Components

  • Per-certificate status: Query by serial number, get a clear “good/revoked/unknown”.
  • Signed responses: OCSP responses are signed by the CA or a delegated responder cert with the appropriate EKU (Extended Key Usage).
  • Freshness & caching: Responses carry ThisUpdate/NextUpdate and caching hints. Servers/clients cache within that window.
  • Nonce support: Guards against replay (client includes a nonce; responder echoes it back). Not all responders use nonces because they reduce cacheability.
  • Transport: Typically HTTP(S). Many responders now support HTTPS to prevent tampering.
  • Stapling support: Offloads lookups to the server and improves privacy/performance.

Benefits & Advantages

  • Lower latency & better UX: With stapling, there’s no extra client-to-CA trip.
  • Privacy: Stapling prevents the CA from learning which sites a specific client visits.
  • Operational resilience: Clients aren’t blocked by transient CA OCSP outages when stapled responses are fresh.
  • Granular revocation: Revoke a compromised cert quickly and propagate status within minutes.
  • Standards-based & broadly supported: Works across modern browsers, servers, and libraries.

When & How to Use OCSP

Use OCSP whenever you operate TLS-protected endpoints (websites, APIs, gRPC, SMTP/TLS, MQTT/TLS). Always enable OCSP stapling on your servers or CDN. Consider must-staple for high-assurance apps (financial, healthcare, enterprise SSO) where failing “closed” on revocation is acceptable and you can support the operational load.

Patterns:

  • Public websites & APIs: Enable stapling at the edge (load balancer, CDN, reverse proxy).
  • Service-to-service (mTLS): Internal clients (Envoy, Nginx, Linkerd, Istio) use OCSP or short-lived certs issued by your internal CA.
  • Mobile & desktop apps: Let the platform’s TLS stack do OCSP; if you pin, prefer pinning the CA/issuer key and keep revocation in mind.

Real-World Examples

  1. Large e-commerce site:
    Moved from CRL checks to OCSP stapling on an Nginx tier. Result: shaved ~100–200 ms on cold connections in some geos, reduced CA request volume, and eliminated privacy concerns from client lookups.
  2. CDN at the edge:
    CDN nodes fetch and staple OCSP responses for millions of certs. Clients validate instantly; outages at the CA OCSP endpoint don’t cause widespread page load delays because staples are cached and rotated.
  3. Enterprise SSO (must-staple):
    An identity provider uses must-staple certificates so that any missing/expired OCSP staple breaks login flows loudly. Ops monitors staple freshness aggressively to avoid false breaks.
  4. mTLS microservices:
    Internal PKI issues short-lived certs (hours/days) and enables OCSP on the service mesh. Short-lived certs reduce reliance on revocation, but OCSP still provides a kill-switch for emergency revokes.

Operational Considerations & Pitfalls

  • Soft-fail vs. hard-fail: Browsers often “soft-fail” if the OCSP responder is unreachable (they proceed). Must-staple pushes you toward hard-fail, which increases availability requirements on your side.
  • Staple freshness: If your server serves an expired staple, strict clients may reject the connection. Monitor NextUpdate and refresh early.
  • Responder outages: Use stapling + caching and multiple upstream OCSP responder endpoints where possible.
  • Nonce vs. cacheability: Nonces reduce replay risk but can hurt caching. Many deployments rely on time-bounded caching instead.
  • Short-lived certs: Greatly reduce revocation reliance, but you still want OCSP for emergency cases (key compromise).
  • Privacy & telemetry: Without stapling, client lookups can leak browsing behavior to the CA. Prefer stapling.

How to Integrate OCSP in Your Software Development Process

1) Design & Architecture

  • Decide your revocation posture:
    • Public web: Stapling at the edge; soft-fail acceptable for most consumer sites.
    • High-assurance: Must-staple + aggressive monitoring; consider short-lived certs.
  • Standardize on servers/LBs that support OCSP stapling (Nginx, Apache, HAProxy, Envoy, popular CDNs).

2) Dev & Config (Common Stacks)

Nginx (TLS):

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
# Ensure the full chain is served so stapling works:
ssl_certificate /etc/ssl/fullchain.pem;
ssl_certificate_key /etc/ssl/privkey.pem;

Apache (httpd):

SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache "shmcb:/var/run/ocsp(128000)"

3) CI/CD & Automation

  • Lint certs in CI: verify AIA OCSP URL presence, chain order, key usage.
  • Fetch & validate OCSP during pipeline or pre-deploy checks:
    • openssl ocsp -issuer issuer.pem -cert server.pem -url http://ocsp.ca.example -VAfile ocsp_signer.pem
  • Renewals: If you use Let’s Encrypt/ACME, ensure your automation reloads the web server so it refreshes stapled responses.

4) Monitoring & Alerting

  • Track staple freshness (time until NextUpdate), OCSP HTTP failures, and unknown/revoked statuses.
  • Add synthetic checks from multiple regions to catch CA or network-path issues.
  • Alert well before NextUpdate to avoid serving stale responses.

5) Security & Policy

  • Define when to hard-fail (must-staple, admin consoles, SSO) vs soft-fail (public brochureware).
  • Document an emergency revocation playbook (CA portal access, contact points, rotate keys, notify customers).

Testing OCSP in Practice

Check stapling from a client:

# Shows if server is stapling a response and whether it's valid
openssl s_client -connect example.com:443 -status -servername example.com </dev/null

Direct OCSP query:

# Query the OCSP responder for a given cert
openssl ocsp \
  -issuer issuer.pem \
  -cert server.pem \
  -url http://ocsp.ca.example \
  -CAfile ca_bundle.pem \
  -resp_text -noverify

Look for good status and confirm This Update / Next Update are within acceptable windows.

FAQs

Is OCSP enough on its own?
No. Pair it with short-lived certs, strong key management (HSM where possible), and sound TLS configuration.

What happens if the OCSP responder is down?
With stapling, clients rely on the stapled response (within freshness). Without stapling, many clients soft-fail. High-assurance apps should avoid a single point of failure via must-staple + robust monitoring.

Do APIs and gRPC clients use OCSP?
Most rely on the platform TLS stack. When building custom clients, ensure the TLS library you use validates stapled responses (or perform explicit OCSP checks if needed).

Integration Checklist (Copy into your runbook)

  • Enable OCSP stapling on every internet-facing TLS endpoint.
  • Serve the full chain and verify stapling works in staging.
  • Monitor staple freshness and set alerts before NextUpdate.
  • Decide soft-fail vs hard-fail per system; consider must-staple where appropriate.
  • Document revocation procedures and practice a drill.
  • Prefer short-lived certificates; integrate with ACME for auto-renewal.
  • Add CI checks for cert chain correctness and AIA fields.
  • Include synthetic OCSP tests from multiple regions.
  • Educate devs on how to verify stapling (openssl s_client -status).

Call to action:
If you haven’t already, enable OCSP stapling on your staging environment, run the openssl s_client -status check, and wire up monitoring for staple freshness. It’s one of the highest-leverage HTTPS hardening steps you can make in under an hour.