How to Fix NET::ERR_CERT_REVOKED

What a revoked certificate actually is

Every TLS certificate is issued by a certificate authority (CA) that vouches for it. A CA can also take that vouching back before the certificate expires, that's revocation. It publishes the revocation two ways: Certificate Revocation Lists (CRLs), which are signed lists of revoked serial numbers, and OCSP (Online Certificate Status Protocol), which lets a client ask "is this specific serial still good?" in real time.

When your browser builds the chain from the leaf certificate up to a trusted root and finds that the leaf (or an intermediate) has been revoked, it fails hard. Chrome and Edge surface that as NET::ERR_CERT_REVOKED. This is different from an expired cert: waiting does nothing, and there is usually no click-through override, because the CA is explicitly saying "do not trust this."

Why you're seeing err_cert_revoked

There are two broad families of cause. The first is that the certificate really was revoked. That happens when a private key was compromised or exposed, when the CA mis-issued the certificate and had to withdraw it, during mass revocation events where a CA invalidates thousands of certs for a compliance defect, or when a certificate was replaced and the old one was revoked but is still being served by a stale load balancer, CDN edge, or cached config.

The second family is local interception. Corporate proxies and antivirus "HTTPS scanning" features sit in the middle and re-sign traffic with their own certificate. If that middlebox presents a revoked intermediate, or your OS trust store is out of date, you can see err_cert_revoked on a site whose real certificate is perfectly fine. The fix in that case lives on your machine, not on the server.

Confirm it's genuinely revoked

Before reissuing anything, prove what you're actually being served. Pull the live certificate and its OCSP status from a machine on a clean network:

• echo | openssl s_client -connect example.com:443 -servername example.com -status 2>/dev/null | openssl x509 -noout -serial -dates, shows the serial and validity window you're actually receiving.
• The -status flag asks for the stapled OCSP response; look for "OCSP Response Status: successful" and a cert status of "revoked" vs "good".
• Open the site in a private window and on a completely different network (e.g. a phone hotspot). If it loads there but not on your corporate Wi-Fi, the revocation is coming from a middlebox, not the CA.
• Cross-check the hostname with an independent SSL checker so you're not fooled by a locally cached or intercepted chain.

If you own the site: reissue, don't wait

You cannot un-revoke a certificate. The only real fix is to issue a fresh one, and, if the revocation was due to key compromise, to generate a brand-new private key rather than reusing the old one. Create a new key and CSR, request a new certificate from your CA, install the full chain (leaf plus intermediates, in order), and reload the server.

The most common trap is a partial rollout. You reissue, but a CDN, reverse proxy, or one node behind your load balancer is still serving the old revoked cert. After deploying, re-run the openssl command against every origin and edge, and confirm the serial matches the new certificate everywhere. If you use Let's Encrypt, force a fresh issuance (for example certbot renew --force-renewal, or delete and re-request the certificate) and restart the web server so it stops holding the revoked one in memory. This is closely related to an expired-cert cleanup, the same install and verification discipline in our expired SSL certificate guide applies here.

If you're just a visitor

You can't override a genuine revocation, and you shouldn't want to, the CA is warning you for a reason. But you can rule out the local causes. Check that your computer's clock and time zone are correct, since a wrong clock skews trust checks. Update your operating system so its root and revocation data are current. Temporarily disable your antivirus's HTTPS or SSL scanning feature and reload; if the error vanishes, that product was injecting a revoked chain and needs updating or reconfiguring.

If none of that helps and other people report the same error on the same site, the problem is on the server side. The most useful thing you can do is tell the site owner the exact error and the certificate serial you saw, that turns a vague "your site is broken" into an actionable report.

Stop it from catching you off guard

Revocation is silent. Nothing warns you the morning a CA pulls a certificate in a mass event, and expiry monitors that only watch the not-after date won't catch it. That's the gap continuous certificate monitoring fills: VigilDog's monitoring validates the live chain and its revocation status on a schedule and alerts you the moment a certificate stops being trusted, not when a customer emails you a screenshot. If you're weighing what to watch, our note on SSL monitoring vs uptime monitoring explains why a site can be "up" and still throwing err_cert_revoked to every visitor.