Understanding SSL Certificate Revocation: CRLs, OCSP, and How to Verify in 2026

Understanding SSL Certificate Revocation: CRLs, OCSP, and How to Verify in 2026

Every time you visit a secure website, your browser checks that the SSL/TLS certificate is valid, unexpired, and—importantly—hasn’t been revoked. Revocation happens when a certificate is compromised (e.g., a private key leak), issued by mistake, or no longer trusted. If browsers didn’t check revocation, a stolen certificate could still be used to impersonate a site, defeating the entire purpose of HTTPS.

Yet revocation checking is surprisingly complex. Two main methods exist: Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). In 2026, the landscape has shifted further with OCSP stapling, Must-Staple extensions, and browser policies that either delay or outright block revocation checks. Let’s dive into how each method works, what’s changed, and how you can verify revocation in practice.

CRLs: The Batch Approach

A Certificate Revocation List is a periodically published list of revoked certificate serial numbers, signed by the issuing Certificate Authority (CA). Clients (browsers, web servers) download the CRL from a URL embedded in the certificate and check if the serial number of a presented cert appears on the list.

CRLs are simple but have major drawbacks:

• Size: CAs like Let’s Encrypt issue millions of certificates, making their CRLs enormous (often exceeding 10 MB). Downloading such files on every connection is impractical.
• Latency: CRLs are updated on a schedule—typically daily or weekly. A certificate revoked an hour after the last CRL publish remains “valid” until the next update.
• Bandwidth: Frequent downloads waste bandwidth on both client and server.

For these reasons, browsers rarely fetch full CRLs today. Instead, they rely on OCSP or lightweight delta CRLs (a newer standard). But CRLs still serve as a fallback and are required for compliance in some industries.

OCSP: Real-Time Status, But Not Without Trade-Offs

OCSP was designed to solve CRLs’ bulkiness. Instead of downloading a whole list, the client asks the CA’s OCSP responder directly: “Is this certificate still good?” The response is a small signed message saying “good,” “revoked,” or “unknown.” Responses are often cached for a few minutes to hours.

OCSP improved timeliness but introduced new problems:

• Privacy: Every request reveals to the CA the exact site a user visits. This is a potential surveillance vector.
• Availability: If the OCSP responder is down, many browsers default to “soft-fail” (allow the connection), defeating revocation checking.
• Latency: An extra round trip to a third-party server can slow down initial page loads.

Enter OCSP stapling. The web server periodically fetches a time-stamped OCSP response from the CA and “staples” it onto the TLS handshake. The client verifies the stapled response without contacting the CA directly—solving both privacy and latency. Modern servers and browsers support stapling, but adoption isn’t universal.

OCSP Must-Staple: Raising the Bar

Even with stapling, an attacker can strip the stapled response and force the client to do a direct OCSP check—which might fail open. To close that loophole, the Must-Staple extension was created (defined in RFC 7633). A certificate with the Must-Staple flag tells the client: “Do not accept this certificate unless you receive a valid OCSP staple during the handshake.”

In 2026, all major CAs offer Must-Staple certificates. Many security-conscious websites use them, and browsers increasingly treat missing staples as a warning. If you’re managing a site, this is one of the easiest wins for better revocation enforcement—especially if you already use SSL Checker to confirm your certificate configuration.

How to Verify Revocation Status in 2026

Whether you’re a website owner, developer, or domain investor, you should periodically verify that your SSL certificates haven’t been revoked—and that your server’s revocation delivery is working. Here are practical methods:

1. Use a Dedicated SSL Checker

The fastest way is to run an online tool that simulates a full client handshake and reports certificate revocations. The SSL Checker on Whose.Domains checks the certificate chain, expiration, and revocation status via both CRL and OCSP. Just enter your domain and see if the certificate is good, the OCSP responder URL, and whether stapling is enabled.

2. Check with OpenSSL (Command Line)

Developers can use openssl s_client to inspect certificates:

openssl s_client -connect example.com:443 -status 2>&1 | grep -A5 "OCSP response"

Look for OCSP Response Status: successful and a next update date. If you see OCSP response no response sent, stapling is not configured. You can also force a CRL fetch by extracting the CRL URL from the certificate and downloading it with curl.

3. Monitor Your Certificate's CRL and OCSP Endpoints

Your certificate likely contains URLs like http://crl.example.com/my.crl and http://ocsp.example.com. Periodically test these endpoints for uptime and correct responses. An expired OCSP responder or a broken CRL distribution point can cause browsers to fail open—making revocation checking useless.

4. Set Up Alerts for Revocation Events

For mission-critical domains, subscribe to CA notification services (e.g., Let’s Encrypt’s Certificate Transparency logs). If a certificate is revoked unexpectedly, you want to know immediately—before browsers stop trusting it. Pair this with a routine DNS Analyzer check to ensure your redirects and backup certs are ready.

Real-World Example: Let’s Encrypt and the 2020 Revocation Debacle

In March 2020, Let’s Encrypt revoked over 3 million certificates due to a CAA record checking bug. Many site owners only found out when visitors started seeing “Your connection is not private” errors. Those who had OCSP stapling enabled saw less impact because their servers had fresh staples—but those without stapling faced broken connections. The lesson? Don’t rely solely on infrequent CRL checks.

Since then, Let’s Encrypt and other CAs have improved systems, but the incident underscores the need for proactive verification. In 2026, revocation speed is measured in minutes, not days—but only if your server participates in the ecosystem.

Conclusion: Best Practices for 2026

• Use OCSP stapling on your web server (most servers like Nginx and Apache support it with minimal config).
• Get certificates with the Must-Staple extension from your CA.
• Regularly verify your site’s revocation status using tools like SSL Checker.
• Monitor CRL/OCSP endpoints for uptime and cache freshness.
• Plan for emergencies: have a backup certificate ready if revocation is forced.

Revocation checking may not be the flashiest part of TLS, but it’s the difference between a secure HTTPS connection and a trust illusion. Stay informed, stay verified.