NET::ERR_CERT_REVOKED: Fix a Revoked Certificate

Problem

Chrome shows Your connection is not private with the code NET::ERR_CERT_REVOKED. Unlike an expiry or a name-mismatch error, this one isn’t about a date or a typo. The certificate authority that issued this certificate has actively withdrawn its trust — it told the world “stop trusting this,” and your visitor’s browser found out. Revocation happens for a reason: a leaked private key, a misissuance, or a replacement cert that retired the old one. The browser is doing exactly what it should. The question is whether the revocation is real for this certificate, or whether you’re still serving a certificate you already replaced.

Symptoms

• The full-page interstitial reads NET::ERR_CERT_REVOKED (Chrome/Edge). Firefox phrases the same condition as SEC_ERROR_REVOKED_CERTIFICATE.
• The certificate’s validity dates are still in range — this is not an expiry error.
• It may appear in one browser but not another, because revocation checking is inconsistent across browsers (see the FAQ).
• The error persists through a page reload and a cache clear, because it’s a property of the certificate, not the page.

Top 3 Causes

1. The certificate really was revoked, and you’re still serving it - The most common operational cause. You (or your CA) rekeyed or reissued, the old certificate got revoked as part of that, but the server, a load balancer, or a CDN edge is still presenting the retired one. The fix isn’t a new certificate — it’s making sure the new one is the one on the wire everywhere.
2. Emergency or CA-side revocation - The CA revoked the certificate because of a key-compromise report, a misissuance, or a mass revocation event (these happen — a CA finds a flaw in how a batch was validated and revokes thousands at once under CA/Browser Forum rules, often on 24-hour or 5-day deadlines). If your certificate got caught in one of these, you’ll get a revocation notice from the CA and need to reissue promptly.
3. A middlebox or the OS store, not the origin - Corporate TLS-inspection proxies re-sign traffic with their own CA and can serve a revoked intermediate. On Windows, Chrome can also inherit a “revoked” verdict from the system certificate store’s own OCSP/CRL check even when Chrome’s CRLSet is silent. If only some networks or some machines see the error, suspect the path, not the certificate.

Diagnose with DechoNet

• SSL Check reads the certificate actually being served — issuer, serial, validity, and chain. Compare the serial and fingerprint against the certificate you think you installed. A mismatch means the old cert is still live somewhere.
• HTTP Check confirms whether the endpoint responds at all once TLS is bypassed, useful when you’ve split a fix across multiple edges and need to know which one is stale.

Resolution Checklist

• Confirm the served certificate on the wire: echo | openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN 2>/dev/null | openssl x509 -noout -serial -fingerprint -dates. Note the serial — that’s the identity that got revoked, not the filename.
• Check the revocation status directly against the CA. If the leaf carries an OCSP URL, query it: openssl ocsp -issuer chain.pem -cert cert.pem -url $(openssl x509 -in cert.pem -noout -ocsp_uri) -no_nonce. A revoked verdict here is authoritative — the browser is right.
• If it’s revoked, reissue from your CA (generate a fresh key and CSR — don’t reuse a key that may have been the reason for revocation), install the new certificate and full chain, and reload every terminating layer: origin, reverse proxy, load balancer, and CDN.
• Re-run SSL Check and confirm the new serial is what’s being served — from more than one vantage point if you use anycast/CDN, because a single stale edge will keep failing for a slice of users.
• If you believe the revocation is a mistake (you never asked for it, the key was never exposed), open a ticket with the issuing CA. Only the CA can un-revoke, and most won’t — expect to reissue regardless.
• If the error only appears behind a corporate network, inspect the chain there: the interception proxy, not your origin, is likely presenting a revoked intermediate. That’s the network operator’s fix, not yours.

When to Escalate

• If the served serial matches your current certificate and the CA’s OCSP responder still says revoked, contact the CA immediately — this is either a real compromise you need to understand or a CA error that only they can correct.
• If you’re caught in a CA mass-revocation event, watch the CA’s status page and the Bugzilla/CA incident threads for the deadline. These carry hard cutoffs (often 24 hours or 5 days); missing the window means the revocation lands whether or not you’ve reissued.
• If revocation checking behavior itself is the puzzle — the cert is valid but one platform flags it — remember that CRLSets are deliberately incomplete. That’s a browser-coverage quirk, not a certificate defect, and there’s nothing to fix on the server.