September 12, 2026
12 min read
By Kokil Thapa | Last reviewed: September 2026
When a private key leaks or a domain changes hands, the certificate may still look valid until expiry. Certificate Revocation: CRL vs OCSP is the decision every HTTPS operator faces: pull a signed list periodically, or ask the CA in real time. I've hit this on production Ubuntu stacks serving SSL/TLS certificates for client portals and eCommerce sites. The wrong default adds latency, breaks pages, or gives a false sense of safety.
Quick answer: Certificate Revocation: CRL vs OCSP comes down to list vs live query. CRLs are signed, cacheable lists of revoked serial numbers; OCSP returns good/revoked/unknown for one certificate. Browsers prefer OCSP, but stapling and short-lived certs reduce the need for either.
What is certificate revocation and why does it matter?
Revocation tells relying parties a certificate must not be trusted, even if dates and signatures check out. Reasons include key compromise, CA mis-issuance, domain loss, or subscriber request. Without revocation, an attacker with a stolen cert can impersonate your site until expiry — sometimes months.
Revocation sits inside PKI and certificate management. The CA maintains status; clients or servers verify it. This is separate from expiry and chain validation covered in the certificate chain of trust.
On legal-tech portals I maintain, HTTPS protects login forms and document uploads. A revoked cert that still works is a real risk. Treat revocation as part of your Linux system administration checklist, not an abstract PKI detail.
When revocation actually fires in production
- Private key exposure on a shared host or leaked
.pemin Git - Employee offboarding without cert rotation
- Domain transfer where the old subscriber still holds a cert
- CA incident or mis-issuance (rare but high impact)
Pair this topic with automate certificate rotation so compromised certs get replaced quickly. Short-lived certs from Let's Encrypt (90 days) shrink the blast radius even if revocation checks fail.
How does a Certificate Revocation List (CRL) work?
A CRL is a signed, time-stamped list of revoked certificate serial numbers. The CA publishes it at a URL embedded in the cert (CRL Distribution Point extension). Clients download the CRL, verify the CA signature, and search for the cert serial.
CRLs are defined in RFC 5280. They scale poorly: a busy CA's CRL can reach megabytes. Clients cache CRLs, but freshness depends on publish interval — often hours to days.
CRL fields you will see in OpenSSL output
openssl crl -in ca.crl -noout -text
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Last Update: Sep 1 12:00:00 2026 GMT
Next Update: Sep 8 12:00:00 2026 GMT
Revoked Certificates:
Serial Number: 0A1B2C3D4E5F6789
Revocation Date: Aug 15 09:30:00 2026 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key CompromiseNext Update tells clients when to refetch. If a cert is revoked after you cached an old CRL, you may trust it until the next update. That window is the main CRL weakness.
CRL advantages and pain points
- Pros: Offline verification possible after download; no per-connection CA query; simple to mirror on internal CDNs
- Cons: Large files; stale cache windows; mobile clients on slow links suffer; privacy leak is minimal (you fetch a public list)
For internal PKI on a corporate LAN, CRL distribution via internal HTTP mirrors still works. For public websites, browsers moved toward OCSP years ago.
How does OCSP check certificate status in real time?
Online Certificate Status Protocol (OCSP) asks the CA: "Is serial X issued by Y still valid?" The responder returns good, revoked, or unknown. See RFC 6960 for the wire format.
Each TLS handshake can trigger an OCSP query unless the response is stapled. That adds RTT to the CA or its responder. I've seen page loads stall when the OCSP responder was slow or blocked by a firewall.
Manual OCSP check with OpenSSL
openssl ocsp -issuer chain.pem -cert site.pem \
-url http://ocsp.exampleca.com \
-header "Host" "ocsp.exampleca.com" \
-resp_text -noverify
Response verify OK
site.pem: good
This Update: Sep 11 10:00:00 2026 GMT
Next Update: Sep 12 10:00:00 2026 GMTUse this during incident response. If you get revoked, rotate the cert immediately and audit logs for misuse.
OCSP stapling shifts work to the server
With stapling, the web server attaches a fresh OCSP response to the TLS handshake. The browser skips a separate CA round trip. Details are in our OCSP and OCSP stapling guide. Stapling is the practical fix for OCSP latency on high-traffic sites like Notary Nepal and other HTTPS portals I host.
Certificate Revocation: CRL vs OCSP — which should you use?
Public browsers already decided: OCSP is default, CRL is fallback or disabled. Your job is to make OCSP fast (stapling), monitor responder uptime, and plan for failure modes. Neither mechanism is perfect; both fail open or closed depending on client policy.
| Criterion | CRL | OCSP |
|---|---|---|
| Data shape | Signed list of all revoked serials | Single-cert status response |
| Typical size | Kilobytes to megabytes | Hundreds of bytes |
| Freshness | CRL publish interval (hours–days) | Minutes with stapling; per-request without |
| Client latency | High first fetch; then cached | Extra RTT unless stapled |
| Privacy | CA sees no per-site query | Responder learns which cert was checked |
| Browser support 2026 | Legacy / limited | Primary path; stapling preferred |
| Ops burden | Mirror large files internally | Enable stapling; watch responder SLA |
Verdict: For public HTTPS in 2026, optimize for OCSP stapling and short cert lifetimes. Keep CRL URLs valid for compliance scanners and enterprise clients. Do not rely on either alone for instant kill-switch; rotate and block at the edge if a key leaks today.
Must-Staple and Certificate Transparency
The TLS Feature extension can require stapled OCSP (status_request). Browsers that enforce it will hard-fail without a staple. Certificate Transparency logs help detect mis-issued certs; they complement but do not replace revocation. Read anatomy of an X.509 certificate to locate CRL and OCSP URLs in your own certs.
Hard-fail vs soft-fail is contentious. Many clients soft-fail OCSP errors to avoid breaking sites when responders go down. That means a network attacker might block OCSP and hide revocation. Certificate pinning is a different trade-off; do not confuse the two.
How do you configure CRL and OCSP on Linux web servers?
Most operators enable stapling on Nginx or Apache after installing SSL certificates on Ubuntu. Certbot from Let's Encrypt usually configures stapling on Nginx automatically.
Nginx OCSP stapling
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
}Nginx needs a public resolver because OCSP fetch happens at runtime. Verify with:
echo | openssl s_client -connect example.com:443 -status 2>/dev/null \
| openssl x509 -noout -ocsp_uri
OCSP Response Status: successful (0x0)Apache OCSP stapling
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLUseStapling on
SSLStaplingCache shmcb:/var/run/apache2/stapling_cache(128000)Reload PHP-FPM after cert changes on Laravel stacks. Opcache can cache old paths if you symlink releases with Deployer — same lesson as support and maintenance runbooks I use on sister legal sites.
Monitoring checklist
- Weekly: confirm stapled response present on all vhosts
- After renewal: re-test OCSP URI resolves from the server
- Alert if cert expires in <14 days (Certbot timer or external monitor)
- Incident: revoke old cert in CA panel, issue new, deploy, verify serial
Application-layer notes for Laravel and WordPress
PHP apps rarely perform revocation checks themselves; the browser and reverse proxy do. Still, outbound HTTPS from Laravel (payment gateways, SMS APIs) uses PHP's OpenSSL stream. Keep CA bundles updated on Ubuntu 22/24. For Nepal-facing apps with digital signatures, see Nepal digital signature certificate for web apps — a different trust model from public Web PKI.
When migrating hosts, copy full chain files, not just the leaf cert. Incomplete chains cause OCSP verify failures. Our website migration process includes a TLS smoke test before DNS cutover.
CDN and managed TLS
Cloudflare, AWS CloudFront, and similar edges handle stapling for you. Confirm in vendor docs — do not assume. For custom origins, origin-pull certs still need valid chains. Use the Base64 encoder/decoder when pasting PEM blocks into ticket systems without breaking line wraps.
What breaks in the real world — and how to fix it?
OCSP responder downtime rarely takes sites offline because of soft-fail. It does weaken revocation assurance. CRL bloat caused Chrome to deprioritize CRL years ago. Enterprise proxies that MITM HTTPS may strip staples or block OCSP ports.
On a production Laravel booking app, a misconfigured ssl_trusted_certificate produced "OCSP response verification failed" in Nginx error logs. The site still served traffic; staples were silently omitted. Fix: point ssl_trusted_certificate at the issuer chain, not the leaf alone.
Another pattern: cron still called an old release path after Deployer symlink swap. Cert renewal succeeded but Nginx read stale paths. Align renewal hooks with your live symlink — same discipline as testing and optimization before go-live.
CRL distribution for your own CA
If you run internal CA for staging, publish CRL over HTTPS and set short nextUpdate intervals. Tools like step-ca or EJBCA automate this. For public sites, you consume CA services; you do not publish CRLs yourself unless you operate PKI.
Audit tools (SSL Labs, testssl.sh) report OCSP and CRL URLs. Run them after every cert change. Target A+ where stapling is scored — it ties to speed optimization because TLS setup affects Time to First Byte.
Future direction: shorter certs, less revocation
Industry push toward 47-day max cert lifetime (CA/B Forum roadmap) reduces dependence on revocation for routine rotation. Automated ACME renewal every 30–60 days is cheaper ops than chasing perfect OCSP uptime. Plan inventory: which vhosts use manual certs vs Certbot vs CDN-managed.
For API backends exposed over mutual TLS, revocation checks may happen in application code or service mesh sidecars. That is beyond browser PKI; treat it as part of API development security design.
Key Takeaways
- CRL is a signed bulk list; OCSP is a per-certificate live status query — browsers favor OCSP in 2026.
- Enable OCSP stapling on Nginx or Apache to avoid extra client latency and improve Core Web Vitals.
- Neither CRL nor OCSP is an instant kill-switch; rotate certs and block at the edge on key compromise.
- Verify staples after every renewal with
openssl s_client -statusand monitor expiry separately. - Short-lived ACME certs (Let's Encrypt) shrink exposure when revocation checks soft-fail.
- Keep full chain files correct; stapling verification fails silently if the trust anchor path is wrong.
People Also Ask
Is OCSP better than CRL?
For public HTTPS, yes. OCSP returns a tiny signed answer for one certificate instead of downloading a large CRL. Browsers and modern servers expect OCSP, often with stapling. CRL remains useful for offline enterprise validation and compliance tooling that batch-processes lists.
What happens if OCSP is unreachable?
Most browsers soft-fail: they accept the cert if the chain and dates are valid. That keeps sites online but weakens revocation detection. Attackers who block OCSP can hide revoked certs. Mitigate with stapling, short cert lifetimes, and immediate rotation after compromise.
Does Let's Encrypt support OCSP stapling?
Let's Encrypt operates OCSP responders for all issued certs. Nginx and Apache can staple those responses when ssl_stapling or SSLUseStapling is enabled and the trust chain file is correct. Certbot's Nginx plugin often enables stapling by default on recent versions.
Can I disable certificate revocation checks?
You should not disable checks on client-facing browsers — you do not control that anyway. On servers, do not disable stapling to "simplify" config; you lose performance and transparency. For internal test labs only, some tools allow skipping revocation verify; never carry that into production Internet-facing hosts.
Ship HTTPS you can trust and maintain
Certificate Revocation: CRL vs OCSP is not a one-time setup choice. It is ongoing ops: stapling, renewal, monitoring, and fast rotation when keys leak. For public sites, choose OCSP with stapling, keep chains complete, and automate renewal. CRL awareness still helps when auditors or enterprise clients ask for list-based proof.
If you want TLS configured, stapling verified, and renewal wired into your deploy pipeline on Ubuntu, see our domain registration and hosting and Court Marriage In Nepal portfolio examples — both run HTTPS portals with document uploads that depend on correct PKI behavior. Questions about your stack? Contact us for a practical review.
Frequently Asked Questions
Certificate revocation tells relying parties a certificate must not be trusted even when dates and signatures look valid. CAs mark certs revoked after key compromise, mis-issuance, domain loss, or subscriber request. Without it, an attacker with a stolen cert can impersonate your site until expiry.
A CRL is a signed, time-stamped list of all revoked certificate serial numbers that clients download and search. OCSP asks the CA in real time whether one specific serial is still valid and returns good, revoked, or unknown. CRLs can reach megabytes; OCSP responses are hundreds of bytes. Browsers prefer OCSP; CRL is legacy fallback.
For public HTTPS, yes. OCSP returns a tiny signed answer per certificate instead of downloading a large CRL. Browsers and modern servers expect OCSP, often with stapling. CRL remains useful for offline enterprise validation and compliance tooling.
Most browsers soft-fail: they accept the cert if the chain and dates are valid. Sites stay online but revocation detection weakens. Attackers blocking OCSP can hide revoked certs. Mitigate with stapling, short cert lifetimes, and immediate rotation after compromise.
The CA publishes a signed list of revoked serial numbers at a URL in the cert's CRL Distribution Point extension. Clients download it, verify the CA signature, and search for the serial. CRLs are defined in RFC 5280. Clients cache them, but freshness depends on publish interval, often hours to days. If a cert is revoked after you cached an old CRL, you may trust it until the next update.
Online Certificate Status Protocol asks the CA whether a specific serial issued by a given CA is still valid. The responder returns good, revoked, or unknown per RFC 6960. Each TLS handshake can trigger a query unless the response is stapled, adding round-trip latency to the CA responder. Use openssl ocsp with the issuer chain and cert during incident response to confirm status.
With stapling, the web server attaches a fresh OCSP response to the TLS handshake so the browser skips a separate CA round trip. That cuts latency on high-traffic HTTPS portals and improves Core Web Vitals. Nginx uses ssl_stapling on; Apache uses SSLUseStapling on. Stapling is the practical fix when comparing CRL vs OCSP for live public sites.
Public browsers already decided: OCSP is default, CRL is fallback or disabled. Your job is to make OCSP fast via stapling, monitor responder uptime, and plan for failure modes. Keep CRL URLs valid for compliance scanners and enterprise clients. Do not rely on either alone as an instant kill-switch; rotate certs and block at the edge if a key leaks today.
Let's Encrypt operates OCSP responders for all issued certs. Nginx and Apache can staple those responses when ssl_stapling or SSLUseStapling is enabled and the trust chain file is correct. Certbot's Nginx plugin often enables stapling by default on recent versions. Let's Encrypt certs are short-lived at 90 days, which shrinks exposure when revocation checks soft-fail.
Enable ssl_stapling on and ssl_stapling_verify on, point ssl_trusted_certificate at the issuer chain, not the leaf alone, and set a public resolver because Nginx fetches OCSP at runtime. Use Certbot from Let's Encrypt on Ubuntu; it often configures stapling automatically. After every renewal, verify with openssl s_client -connect yourdomain:443 -status and confirm OCSP Response Status shows successful.
Run openssl s_client -connect example.com:443 -status and check that OCSP Response Status is successful. Also confirm the OCSP URI resolves from the server with openssl x509 -noout -ocsp_uri. Include stapling checks in a weekly monitoring checklist alongside alerts for certs expiring in under 14 days. Re-test after every Certbot renewal or Deployer symlink swap because stale cert paths can silently drop staples.
A misconfigured ssl_trusted_certificate pointing at the leaf alone causes OCSP response verification failed in Nginx logs; staples are silently omitted while traffic still serves. Fix by pointing it at the full issuer chain. Incomplete chain files after host migration also break OCSP verify. Cron jobs calling old release paths after a Deployer symlink swap can leave Nginx reading stale cert paths even after renewal succeeds.
Revoke when a private key is exposed on a shared host or leaked in Git, after employee offboarding without cert rotation, when a domain transfers and the old subscriber still holds a cert, or after a CA incident or mis-issuance. Pair revocation with immediate cert rotation. On legal-tech portals with login forms and document uploads, a revoked cert that still works is a real impersonation risk until replaced.
You should not disable checks on client-facing browsers because you do not control browser policy anyway. On servers, do not disable stapling to simplify config; you lose performance and transparency. Some internal test lab tools allow skipping revocation verify, but never carry that into production Internet-facing hosts. Ship HTTPS you can trust and maintain with stapling, renewal monitoring, and fast rotation when keys leak.
The TLS Feature extension can require stapled OCSP via status_request. Browsers that enforce Must-Staple hard-fail without a staple, unlike the soft-fail behavior when live OCSP is unreachable. Certificate Transparency logs help detect mis-issued certs but do not replace revocation. Hard-fail vs soft-fail remains contentious because strict enforcement breaks sites when responders go down, while lenient policy lets network attackers block OCSP and hide revocation.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
