Certificate Revocation: CRL vs OCSP

By Khimananda Oli | Last reviewed: August 2026

Certificate Revocation: CRL vs OCSP is a decision that directly impacts your site’s latency, availability during CA outages, and compliance posture. When a private key leaks or an employee leaves with credentials, you must revoke certificates instantly, but the mechanism you choose determines whether users experience slow handshakes or blocked connections. Understanding the operational differences between Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP) prevents both security gaps and performance regressions in production environments.

How Does Certificate Revocation: CRL vs OCSP Actually Work?

Before configuring servers, you need to understand the fundamental data flow differences. Both mechanisms solve the same problem—distributing "this serial number is no longer valid"—but they do so with opposite architectural assumptions. If you are managing SSL certificates on Ubuntu or any Linux server, this distinction dictates your Nginx/Apache config and monitoring strategy.

In the CRL model, the Certificate Authority periodically publishes a signed file containing every revoked serial number. Clients download this entire list, cache it locally, and check incoming certificates against it. The advantage is resilience: once cached, validation works even if the CA goes offline. The disadvantage is size and freshness. A large enterprise CA might issue millions of certificates; the resulting CRL can reach tens of megabytes, causing timeouts on slow networks and stale windows where recently revoked certs remain trusted until the next update cycle.

OCSP flips this model. Instead of downloading a list, the client sends a lightweight HTTP request to an OCSP responder asking specifically about one serial number. The responder replies with a signed "good," "revoked," or "unknown" status. This keeps payloads tiny and information current, but introduces two critical failure modes: added latency to every TLS handshake (an extra round-trip to a third-party server) and a privacy leak where the CA learns which sites every user visits. In high-compliance environments like those requiring SOC 2 evidence collection, that telemetry can itself become an audit finding.

Why Is OCSP Stapling the Recommended Solution for Production?

OCSP Stapling solves both the latency and privacy problems by shifting the query from the client to the server. During the TLS handshake, your web server presents not just the certificate but also a fresh, time-stamped OCSP response obtained proactively from the CA. The client verifies the stapled response without ever contacting the OCSP responder directly. This eliminates the extra RTT for users and prevents the CA from tracking individual visitors—a win for both Core Web Vitals and GDPR/privacy compliance.

Configuring OCSP Stapling in Nginx

On Ubuntu 24.04+ with Nginx 1.26+, enable stapling in your server block. Note that Nginx requires the full certificate chain (including intermediates) to validate the OCSP response signature. Missing intermediates is the most common reason stapling silently fails.

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/example.com.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # Enable OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # Required: trusted CA bundle for verifying OCSP responses
    ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;

    # DNS resolver for OCSP responder hostname lookup
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;
}

After reloading Nginx, verify stapling is active using OpenSSL. A successful output includes "OCSP Response Status: successful." If you see "no response sent," check your error log for DNS resolution failures or missing intermediate certificates. For teams running Kubernetes ingress with cert-manager, ensure the Issuer resource includes the full chain and that the ingress controller supports stapling passthrough.

Apache and HAProxy Considerations

Apache uses SSLUseStapling On inside the VirtualHost and requires SSLStaplingCache shmcb:/run/apache2/ocsp(128000) globally. HAProxy enables it via ssl-stapling on in the bind line. Across all platforms, the pattern is identical: the server caches responses and refreshes them before expiry. Set cache TTLs to roughly half the OCSP response validity period (typically 1–7 days) to avoid serving stale responses during CA maintenance windows.

When Should You Still Use CRLs Over OCSP?

Despite OCSP stapling's advantages, CRLs remain relevant in specific scenarios. Understanding when to retain them prevents over-engineering. I have audited environments where removing CRL distribution points actually broke legacy medical devices and industrial control systems that lack OCSP client support entirely.

• Air-gapped and restricted networks: Government and defense systems in Nepal and abroad often cannot reach public OCSP responders. CRLs distributed via internal LDAP, SMB shares, or USB media provide the only viable revocation channel.
• Legacy IoT and embedded devices: Many devices shipped before 2015 implement only CRL checking. Updating firmware may be impossible; you must maintain CRL infrastructure for their lifetime.
• High-volume internal PKI: Enterprise CAs issuing thousands of short-lived certificates daily can overwhelm OCSP responders. Delta CRLs (incremental updates) reduce bandwidth while keeping validation local and fast.
• Audit and forensic requirements: Some compliance frameworks require retaining historical revocation records. CRL archives provide immutable, timestamped snapshots useful during incident investigations long after OCSP responses have expired.

For public-facing web services targeting modern browsers, however, CRLs should be considered a fallback at best. Most browsers have deprecated direct CRL fetching due to performance concerns, relying instead on OCSP stapling or proprietary mechanisms like Chrome's CRLSets.

How Do CRL and OCSP Compare Across Key Operational Criteria?

The following table synthesizes the trade-offs based on production deployments across AWS, Azure, and on-premises environments. Use it to justify architectural decisions to stakeholders who need concrete comparisons rather than theoretical explanations.

A critical nuance missing from many guides: browser "soft fail" behavior. When an OCSP responder times out, most browsers accept the certificate anyway to avoid breaking sites during CA outages. This means pure OCSP without stapling provides weaker security guarantees than commonly assumed. Stapling with ssl_stapling_verify on enforces hard fail at the server level, ensuring revoked certificates never reach users regardless of client policy.

How Do You Monitor and Validate Revocation Infrastructure Reliably?

Configuration alone is insufficient. Revocation infrastructure fails silently, and discovering broken stapling during an audit or incident is unacceptable. Implement proactive validation as part of your monitoring fundamentals.

1. Automated handshake testing: Run openssl s_client -connect example.com:443 -status hourly via cron or Prometheus blackbox exporter. Parse the OCSP Response Status field. Alert on anything other than "successful" for stapled hosts.
2. CRL freshness metrics: For CRL-dependent systems, monitor the nextUpdate timestamp. Alert when current time exceeds 80% of the validity window. Stale CRLs mean revoked certificates are being accepted.
3. Responder latency SLOs: Track OCSP responder p95 latency separately from your application SLOs. A slow responder degrades TLS performance even with stapling enabled during cache refresh cycles. Target <200ms p95 for public responders.
4. Certificate transparency cross-checks: Subscribe to CT logs for your domains. Cross-reference newly logged certificates against your revocation database. Unauthorized certificates that aren't revoked represent active compromise vectors.
5. Fault injection testing: Periodically block OCSP responder access in staging to verify graceful degradation. Confirm whether your stack fails open or closed, and document the behavior for incident runbooks. Teams practicing chaos engineering should include revocation path failures in their game days.

For compliance-heavy environments, automate evidence collection. Scripts that capture OCSP responses and CRL snapshots with timestamps satisfy SOC 2 CC6.1 and ISO 27001 A.8.16 controls without manual intervention during audits. Store these artifacts in immutable object storage with retention matching your certification period.

Making the Right Choice for Your Environment

Certificate Revocation: CRL vs OCSP is not an abstract academic choice—it determines whether your TLS infrastructure survives CA outages, passes compliance audits, and delivers acceptable page load times. For public web services in 2026, OCSP stapling is the default recommendation. Reserve CRLs for air-gapped networks, legacy device fleets, and forensic archival. Never rely on plain client-side OCSP without understanding soft-fail implications.

If you are designing PKI for a multi-cloud deployment or preparing for a security audit and need hands-on guidance tailored to your stack, reach out through my contact page. I help teams build revocation infrastructure that is secure, observable, and audit-ready from day one.