ERR_CERT_REVOKED website error explained

What it means

NET::ERR_CERT_REVOKED is the Chrome error shown when the browser receives an indication that the site's certificate has been revoked, meaning the issuing certificate authority (CA) has invalidated it before its natural expiry date. A revoked certificate is different from an expired one: an expired certificate simply ran out of time, while a revoked one was actively cancelled. The date-invalid error covers expiry; this error is about a deliberate early invalidation.

Browsers check revocation through different mechanisms. Modern Chrome relies primarily on stored revocation information rather than a live query each visit, while other clients may query the Online Certificate Status Protocol (OCSP) or a certificate revocation list (CRL). The revocation mechanisms reference explains the difference between CRLs, OCSP and the browser's built-in trust lists. Because browsers can disagree on which check they use, a revoked certificate that is blocked immediately in one engine may be accepted for a while in another, which makes this error intermittent across users.

Why CAs revoke

A CA revokes a certificate when it should no longer be trusted before its expiry. The common legitimate reasons are:

• A compromised private key. If the private key is suspected stolen or exposed, the CA cancels the certificate so the stolen key can no longer be used to impersonate the site.
• A certificate issued incorrectly or for the wrong entity. If a certificate was issued by mistake, the CA retracts it.
• The holder requested it. A domain transferring to new ownership, or a certificate replaced and explicitly revoked, leads to early revocation.
• The CA determined the request was fraudulent. Certificates issued to the wrong party or on invalid evidence are revoked.

Revocation is a safety feature, not always an error on your side. It often means the key or the issuing process was compromised, so treating it as "just reinstall the same thing" is wrong.

How to respond

When ERR_CERT_REVOKED appears, the correct response is to replace the certificate rather than suppress the warning.

1. Confirm it is really revoked. Query the certificate's serial number against the issuing CA's OCSP responder or CRL. An external TLS checker can report the revocation status directly. Confirm it is your certificate and not a client-side proxy injecting its own.
2. Do not reuse the old private key. Assume the key may be compromised. Generate a fresh key pair and obtain a brand new certificate, because reissuing over the same key defeats the purpose of revocation. The certificate hierarchy explains how a new key pairs with a leaf and intermediates.
3. Reissue from the CA. Order a new certificate through the control panel or client, install the fresh leaf and its intermediate chain, then point the server at the complete chain rather than a leaf-only file, following the renewal checklist.
4. Verify the chain and SAN coverage. Confirm the new certificate lists the exact hostname in its Subject Alternative Name, including www if used, so visitors do not next hit an authority or name mismatch.
5. Distribute and re-test. The new certificate needs to be deployed on every server behind the domain, and any CDN or load balancer holding the old certificate must be updated. Test from a private window and a separate device after deploying, because revocation checks and cached chains differ per client.

Do not tell visitors to click "proceed anyway" when this error appears, because a revoked certificate may follow a key compromise, and bypassing it removes a genuine security boundary. The safe path is always the same: revoke the compromised key from use, obtain a fresh certificate with a new key, and confirm the new chain is served and current. For sensitive deployments or where the CA report is unclear about why revocation happened, involve the domain registrar and certificate provider, because the root cause may be an exposure that needs a wider response than a single certificate swap.