SEC_ERROR_REVOKED_CERTIFICATE in Firefox: Fix

Problem

Firefox blocks the page with SEC_ERROR_REVOKED_CERTIFICATE — Secure Connection Failed. The certificate is not trusted because it was revoked. — and there’s no “Accept the Risk” button to click past it. The site often loads fine in Chrome, which sends everyone chasing the wrong theory: that Firefox is broken or overzealous. It isn’t. Firefox is telling you the certificate in this connection appears on a revocation list, and it means it. The only real questions are which certificate — the real server’s, or one added between you and it — and why it was revoked.

Symptoms

• Firefox shows Secure Connection Failed with Error code: SEC_ERROR_REVOKED_CERTIFICATE and “The certificate is not trusted because it was revoked.”
• There is no override link — unlike an expired or self-signed certificate, you can’t add an exception.
• The exact same URL loads without warning in Chrome or Edge, making it look like a Firefox-only bug.
• It hits either one specific site (and only that site) or every HTTPS site at once — the two patterns point at very different causes.
• On the all-sites version, you’re often behind antivirus HTTPS scanning or a corporate proxy, or on a managed/work machine.

What This Error Actually Means

Revocation is how the certificate system says “trust this one no longer” before it naturally expires — after a key compromise, a misissuance, or a certificate replaced during an incident. The hard part has always been getting that verdict to your browser quickly. The old answer was OCSP: a live query to the CA at connection time asking “is this serial still good?” It was slow (it blocked the TLS handshake — about 100 ms at the median, per Mozilla), it leaked your browsing to the CA, and it failed open when the responder was down.

Firefox has now largely replaced that. Since Firefox 137 (April 2025), CRLite is on by default — Mozilla aggregates every CA’s revocations from Certificate Transparency logs and published CRLs into a compressed filter cascade and ships it to the browser, so Firefox checks revocation locally, against a near-complete list, with no phone-home. Firefox 142 (August 2025) went further and stopped doing live OCSP for domain-validated certificates altogether. For revoked intermediate CA certificates there’s a second, older list — OneCRL, carried since Firefox 37 in 2015.

That history is the whole diagnosis. SEC_ERROR_REVOKED_CERTIFICATE now fires because a certificate in your chain matched an entry in a list Firefox already holds — not because a flaky network check hiccupped. And because that list is far more complete than Chrome’s hand-curated CRLSet, Firefox catches revoked certificates Chrome silently accepts. The browser that shows the error is the one telling you the truth. Firefox’s own text is famously unhelpful about why — it names the state but not the offending certificate (Bugzilla 1316342) — so the work is figuring out which certificate is on the list.

Top 3 Causes

1. The server is still serving a genuinely revoked certificate. The CA revoked this certificate — key compromise, misissuance, or an incident replacement — but an old node, a stale load balancer, or a forgotten deployment is still handing it out. Firefox’s CRLite has the revocation and blocks it; Chrome’s CRLSet doesn’t carry it, so Chrome loads the site and makes it look like Firefox is wrong. This is the classic single-site failure. The fix is server-side: deploy the current certificate everywhere and stop serving the revoked one.
2. A local TLS interceptor is inserting a revoked intermediate. Antivirus HTTPS scanning or a corporate proxy re-signs every site with its own CA. If that intermediate is in OneCRL, every re-signed page throws SEC_ERROR_REVOKED_CERTIFICATE. The signature of this cause is scope: it’s not one site, it’s all of them. The fix is on the intercepting software or its administrator, not on any website.
3. A revoked intermediate in the real chain. Less common, but a CA-level distrust or an intermediate that was revoked (and landed in OneCRL) takes down every leaf certificate issued beneath it — so a specific site, or a set of sites from one issuer, fails while the rest of the web is fine. Here the site operator has to re-issue under a current, trusted intermediate.

Diagnose with DechoNet

• SSL Check runs a full TLS handshake against the host from outside your network and reports the certificate the real server actually presents — its issuer, serial, validity, and chain. Compare that to what your Firefox is choking on. If the external check shows the server serving an old or replaced certificate, you’ve confirmed a server-side revoked-cert problem (and explained why Chrome, with its thinner list, let it through). If the external check shows a clean, current certificate but Firefox still says revoked, the revoked certificate is being added on your side — a local interceptor — because the wire from the real server is clean.
• HTTP Check fetches the site from outside your browser entirely. A normal response from our side, while your Firefox fails, is more evidence the block is local to your machine rather than the origin.

Resolution Checklist

• Read the served certificate first. Run an external SSL Check and note the issuer and serial the server presents. This tells you whether you’re looking at a server-side revoked cert or a locally-inserted one before you change anything.
• Check the scope. One site → suspect the server (or its issuing intermediate). Every HTTPS site → suspect local TLS interception (antivirus, proxy). The pattern is the fastest branch you have.
• If it’s your server, deploy the current certificate everywhere. Replace the revoked certificate on all nodes and load balancers — a single stale endpoint is enough to keep tripping Firefox. Don’t rely on Chrome loading it as proof you’re done; Chrome’s CRLSet may simply not carry the revocation.
• If it’s every site, inspect the local interceptor. Temporarily disable antivirus HTTPS/SSL scanning or step off the corporate proxy and retest. If the error clears, the revoked intermediate was being inserted locally — fix it there.
• Don’t try to override it. There is no exception button by design; a revoked certificate is one you were explicitly warned not to trust. Bypassing it defeats the entire point of revocation.
• Rule out a wrong clock only if CRLite acts stale. CRLite is versioned in time; a wildly incorrect system clock can, rarely, confuse revocation state. Correct the clock and let Firefox refresh its filter.

When to Escalate

• If the external SSL check shows a current, non-revoked certificate and Firefox still blocks the site on that one machine, escalate to whoever manages the endpoint or the machine’s security software — the revoked certificate is being introduced by a local interceptor you may not control.
• If it’s your certificate that’s revoked, treat it as an incident, not a browser quirk: find out why the CA revoked it (a key compromise or misissuance is not something to paper over), obtain a fresh certificate, and confirm every node serves it. The fact that other browsers still load the old one is not reassurance — it’s a gap in their revocation coverage that Firefox happens not to share.