APNIC: Why SSL Certificate Revocation Is Still Broken
APNIC's April 2026 analysis shows certificate revocation (OCSP/CRL) remains fundamentally broken. Shorter-lived certificates are the real fix — here's why.
Six weeks into the 200-day certificate era, the industry is still grappling with a problem that predates modern TLS by decades. A detailed analysis published last week by APNIC — the regional internet registry for Asia-Pacific and a major voice in internet infrastructure — makes the case plainly: certificate revocation is broken, it has been broken for a long time, and shorter certificate lifetimes are the industry’s most realistic path to fixing it.
The timing of the analysis is no accident. With maximum TLS certificate validity now capped at 200 days and on a schedule to reach 47 days by 2029, the mechanics of certificate trust are more relevant to day-to-day operations than they have ever been.
The Problem With “Revoked” Certificates
When a private key is compromised, or a certificate is found to have been mis-issued, the CA is supposed to be able to revoke it — mark it as no longer trustworthy before its scheduled expiration. Two mechanisms exist to tell the world about revocations: Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP).
Both have fundamental problems.
CRLs are essentially large files listing every revoked certificate a CA has issued. Retrieving and checking a CRL for every TLS connection is prohibitively slow, and the lists themselves can lag the actual revocation event by up to nine days. Nobody actually uses CRLs for real-time session validation. The APNIC analysis confirmed this directly: “Do we use CRLs in this manner? No. It takes too long to load the CRLs and perform the CRL checking actions, and nobody is willing to pay this time penalty.”
OCSP improved on CRLs by allowing a client to query a CA’s responder for the status of a single certificate. But it has its own set of problems: it’s slower than ideal, it leaks browsing behavior back to the CA (because the CA can see which certificate you’re checking, and when), and — most critically — the most-used browser in the world doesn’t do it at all.
Chrome Stopped Checking OCSP in 2012
The APNIC analysis tested the three major desktop browsers and found that Chrome does not perform OCSP-based revocation checks and has not since 2012. Safari and Firefox both check OCSP; Chrome does not. Instead, Chrome uses its own CRLSet mechanism, a compressed set of high-priority revocations that ships with browser updates — an approach that covers only the most severe incidents.
Chrome holds roughly 65% of global browser market share. That means the majority of the world’s TLS connections are made without any real-time revocation check. A certificate could be revoked by its CA today, and the typical Chrome user visiting a site using that certificate would never know.
As the APNIC analysis puts it: “If we are going to rely on OCSP to perform certificate revocation, then it seems that this is largely an ineffectual measure, as the dominant browser platform, Chrome, does not perform OCSP checks.”
What This Means for Everyday Certificate Management
The practical consequence is not that revocation is useless — it matters for high-severity incidents, particularly for EV certificates and code signing — but that it cannot be relied upon as a safety net for most deployments. If a key is compromised or a certificate is mis-issued, revocation reduces the blast radius for some browsers and some clients, but it does not eliminate it.
The industry has implicitly acknowledged this for years, which is exactly why the CA/Browser Forum pushed for shorter certificate lifetimes. A certificate valid for 47 days represents a 47-day window of exposure in the worst case. Compare that to the 398-day certificates that were standard just a few months ago: a revocation failure on a year-long certificate could leave a compromised credential trusted for nearly 13 months.
Let’s Encrypt has gone further. Since January 2026, 6-day certificates have been generally available. A certificate that expires in less than a week makes revocation largely academic — by the time an incident is detected, investigated, and acted upon, the certificate would have expired on its own.
The Lesson for Certificate Owners
APNIC’s point lands differently now that 200-day certificates are here: frequent renewal is not paperwork. It is part of the security model. Keeping certificate lifetimes short limits what an attacker can do with a compromised or mis-issued certificate, regardless of whether revocation checking is working correctly on the other end.
That does not make managing more frequent renewals any easier. A certificate that expires every 200 days needs to be tracked and renewed at least twice as often as an annual certificate. By 2027, when the cap drops to 100 days, that frequency doubles again.
Stay Ahead of the Renewal Schedule
The practical takeaway is boring but important: automate renewals, and know when every certificate is due to expire. To avoid a lapse in coverage, consider using SSLcalendar.com to receive timely reminders before your certificates expire. As renewal windows shrink, missing a renewal date gets easier, not harder. If you also need chain checks, TLS configuration checks, and inventory across domains, SSLboard.com covers that side.
Certificate revocation was designed for a different era. Shorter lifetimes are the fix the internet is actually using.
Sources: Revocation of X.509 certificates — APNIC Blog, TLS Certificate Rule Changes: 2026–2029 Timeline — DigiCert, 6-day and IP Address Certificates are Generally Available — Let’s Encrypt