How to fix NET::ERR_CERT_REVOKED Error

Most browser certificate warnings mean something was configured wrong. NET::ERR_CERT_REVOKED is different. It means the certificate was issued correctly, was accepted as genuine, and then the Certificate Authority that issued it deliberately cancelled it before its expiry date. Nothing is broken in the sense of a typo in a config file. Somebody decided this certificate should no longer be trusted.

That makes it the most serious error in the certificate family, and also the one surrounded by the most outdated advice.

Quick answer:

NET::ERR_CERT_REVOKED means the Certificate Authority cancelled the site’s certificate before its expiry date. Chrome does not learn this by asking the CA: it switched off online OCSP and CRL checks in 2012 and instead consults a pre-compiled list called a CRLSet, which always runs and cannot be disabled, but is deliberately incomplete. The error is therefore a positive finding rather than a network glitch, though its absence does not prove a certificate is unrevoked. A revoked certificate cannot be un-revoked.

The only fix is on the server: get a replacement issued and installed, with a new private key if the revocation was for key compromise. Common causes are key compromise, CA mis-issuance, a domain changing hands, and mass revocation events, where Baseline Requirements can give the operator as little as 24 hours. Visitors cannot fix this and should not click past it, because the usual reason for revocation is an exposed private key.

What NET::ERR_CERT_REVOKED Actually Means

Revocation is the mechanism that lets a Certificate Authority withdraw a certificate it already issued. A certificate carries a fixed expiry date, but circumstances change before that date arrives: a private key leaks, a certificate turns out to have been issued against the wrong evidence, a domain moves to a new owner. Revocation is how the CA says this certificate is no longer valid, ahead of schedule.

Chromium tracks this outcome as error -206. Its own note on the code is worth knowing: the browser is technically capable of ignoring the error, but the source explicitly says doing so is inadvisable. That is a stronger position than Chromium takes on most certificate failures.

The distinction that matters most is between this code and its two neighbours, because a great deal of published troubleshooting confuses them:

• NET::ERR_CERT_REVOKED (-206): the browser obtained revocation information and that information says the certificate is revoked. That is this page.
• NET::ERR_CERT_UNABLE_TO_CHECK_REVOCATION (-205): the browser tried to establish revocation status and could not. Chromium describes it as revocation information simply not being available.
• NET::ERR_CERT_NO_REVOCATION_MECHANISM (-204): the certificate offers no way to determine revocation status at all.

This matters because a common claim about this error is that DNS problems or network trouble reaching a revocation server can produce it. They cannot. A browser that fails to reach a revocation responder has learned nothing about the certificate, which is precisely the -205 case. Reaching the conclusion “revoked” requires positive evidence, and a failed network request is not evidence.

The other Chrome certificate codes describe unrelated failures. NET::ERR_CERT_DATE_INVALID (-201) is expiry or a wrong device clock, covered in how to fix NET::ERR_CERT_DATE_INVALID. NET::ERR_CERT_AUTHORITY_INVALID (-202) is a chain that does not reach a trusted root, covered in how to fix NET::ERR_CERT_AUTHORITY_INVALID. NET::ERR_CERT_COMMON_NAME_INVALID (-200) is a hostname mismatch, covered in how to fix ERR_CERT_COMMON_NAME_INVALID. All of them appear under the same Your connection is not private headline, so read the code, not the headline.

Firefox reports the same condition as SEC_ERROR_REVOKED_CERTIFICATE. Safari prints no code and states that the certificate is invalid. Edge, Brave and Opera are built on Chromium and show the Chrome wording.

How Chrome Finds Out That a Certificate Is Revoked

This is the part almost every guide gets wrong, and it changes what the error tells you. Chrome does not, for most certificates, contact the Certificate Authority to ask whether a certificate is still valid.

Online revocation checks were switched off in 2012

Chrome disabled default online revocation checking, both OCSP and CRL fetching, from version 19 onward. The reasoning was published by Adam Langley of the Chrome security team in February 2012: an attacker who can intercept a connection can also block the revocation lookup, and because browsers treated a failed lookup as success, the check collapsed exactly when it was needed. His summary was that “soft-fail revocation checks are like a seat-belt that snaps when you crash”.

Online checks were also slow and leaked browsing history to the CA, which learns the IP address and the site being visited on every lookup. The Chromium project states plainly that online OCSP and CRL checks are not generally performed by Chrome. Microsoft Edge inherited the same behaviour when it moved to the Chromium engine, and Microsoft’s own documentation says online revocation checks are disabled by default because they do not provide a significant security benefit.

CRLSets replaced them

Instead of asking at connection time, Chrome ships the answer in advance. Google crawls the CRLs that CAs disclose to the Common CA Database, plus intermediates discovered through Certificate Transparency, and compiles a compact list called a CRLSet, which is pushed to browsers through the component updater without needing a restart. You can see the version your browser holds at chrome://components.

Two properties of CRLSets follow from this design, and both matter for diagnosis:

• CRLSet checking is always on. Chromium’s certificate verifier treats it as unconditional, independent of the online revocation settings, so there is no configuration in Chrome that turns this error off.
• CRLSets are not complete. Chromium describes them as primarily an emergency blocking mechanism carrying a subset of known revocations. Since 2024, Chrome has supported revocations carrying the key compromise reason code and enforces them, with affected certificates blocked within roughly 24 to 48 hours. Google is explicit that this covers day-to-day revocation but not mass revocation events, because a CRLSet has a maximum size.

Chrome will also honour a revoked status delivered two other ways: an OCSP response stapled by the server itself during the handshake, and a full online check when the chain ends at a locally installed root rather than a public one. That second case is switched on by an enterprise policy, RequireOnlineRevocationChecksForLocalAnchors, which ships disabled and is normally set only on managed devices. It applies to company-internal CAs and to TLS-inspecting proxies.

What this means when you actually see the error

Because Chrome is not making a speculative lookup that might fail, a visitor seeing NET::ERR_CERT_REVOKED is seeing a positive result. The certificate matched an entry Google compiled from a CA’s own published revocation data, or the server stapled a revoked status, or a locally trusted issuer reported it revoked. It is not a transient glitch and it is not a false alarm caused by a slow network.

The reverse does not hold. Because CRLSets are incomplete, not seeing this error does not prove a certificate is unrevoked. Chrome may simply never have been told. This asymmetry is the single most useful thing to understand about the error.

Firefox works differently, and its coverage is much wider. Since Firefox 137 it ships CRLite by default on desktop: a compressed encoding built from the same CRLs that CAs disclose to the Common CA Database, covering the certificates visible in Certificate Transparency logs. Firefox updates it roughly every 12 hours and queries it locally, so no lookup is sent to the CA. The practical difference is that Chrome filters that data down to a subset and Firefox does not, so a certificate can be blocked in Firefox while Chrome still loads it.

Why a Certificate Gets Revoked

If you own the site, the reason determines what you have to do next, and in one case it determines whether reissuing alone is even sufficient.

• Private key compromise. The key was exposed in a repository, a backup, a leaked image, or a server breach. Anyone holding it can impersonate your site, so the certificate must go. This is the one case where a new key pair is mandatory, not optional.
• CA mis-issuance. The certificate was issued through a process that later turned out not to meet the rules. Nothing is wrong with your server, and you may be the last to know.
• Loss of domain control. The domain was sold, transferred, or allowed to lapse. The previous holder’s certificate has to be revoked so it cannot be used against the new owner.
• Subscriber request. Someone with access to the account or the key asked for revocation, which occasionally happens by accident during decommissioning.
• CA distrust. Where a root program removes trust in a CA entirely, browsers usually signal this through dedicated codes rather than revocation, as happened with the legacy Symantec roots and NET::ERR_CERT_SYMANTEC_LEGACY. The remedy is the same: reissue through a CA in good standing.

Mass revocation events, and why you may get 24 hours’ notice

The scenario that catches most site owners off guard is one where they did nothing wrong. CA/Browser Forum Baseline Requirements bind the CA to a deadline once a problem is confirmed. Section 4.9.1.1 splits the reasons into two groups: revocation within 24 hours for confirmed key compromise, a subscriber’s written request, or evidence that the domain validation behind the certificate cannot be relied upon, and within 5 days for the remaining qualifying problems, including a certificate that simply was not issued in accordance with the rules. The CA has no discretion to extend these for customer convenience.

The result is periodic mass revocations. In March 2020, Let’s Encrypt found a bug in how it rechecked CAA records and identified over 3 million affected certificates, revoking them on a few days’ notice. In July 2024, DigiCert revoked more than 83,000 certificates belonging to around 6,800 customers after discovering that a random value used in CNAME-based domain validation had been missing its required underscore prefix, and the 24-hour rule applied.

If your site broke overnight with no deployment on your side, check your CA’s status page and the email address on the certificate account before assuming a server fault.

Confirm Whether the Certificate Is Really Revoked

Before reissuing anything, verify the claim independently. This takes a few minutes and rules out the possibility that you are chasing a locally intercepted connection.

The trap: OpenSSL will tell you the certificate is fine

The standard chain-checking command does not check revocation. Run it against a certificate that is definitively revoked and it still reports success:

openssl s_client -connect revoked.badssl.com:443 -servername revoked.badssl.com < /dev/null 2>/dev/null | grep "Verify return code"

    Verify return code: 0 (ok)

The host revoked.badssl.com exists specifically to serve a revoked certificate, and Chrome blocks it with exactly this error. OpenSSL returns 0 because it validated the signature chain and the dates, which is all it was asked to do. Revocation status is a separate lookup that it does not perform by default. Treating Verify return code: 0 (ok) as proof that a certificate is not revoked is a mistake, and it is why so many owners conclude the browser is wrong.

Check the CRL yourself

The authoritative answer is in the Certificate Revocation List published by the issuing CA. First read the serial number of the certificate your server is presenting:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -serial -issuer -dates

Then find the CRL distribution point recorded in the certificate:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -A 4 "CRL Distribution Points"

That prints a URL ending in .crl. Download it and search it for your serial number, remembering that CRLs are distributed in DER form:

curl -sS -o cert.crl "http://example-ca.crl-url/xx.crl"
openssl crl -inform DER -in cert.crl -noout -text | grep -A 2 "YOUR_SERIAL_NUMBER"

A match confirms the revocation and gives you the date it happened:

    Serial Number: 05C391E061DE6588F670B613F061AEF4B3A1
        Revocation Date: Jul 14 21:01:28 2026 GMT

No output means the serial is not on that list, so the certificate has not been revoked by that CA. Note that on macOS the bundled openssl command is actually LibreSSL, which does not support the newer -ext option some guides use for reading extensions. The grep form above works on both.

The grep is only a text match. To make OpenSSL itself rule on the certificate, pass the same CRL to its verifier along with the chain the server sent:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null 2>/dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/' > chain.pem
openssl x509 -in chain.pem -out server.pem
openssl verify -crl_check -CRLfile cert.crl -untrusted chain.pem server.pem

A revoked certificate fails with error 23, while a good one prints only OK:

error 23 at 0 depth lookup: certificate revoked

This is the check that the plain handshake test earlier does not perform, and it fails safe: if the CRL you supplied does not cover the certificate, you get error 3, unable to get certificate CRL, rather than a misleading pass.

Why OCSP is probably not an option any more

Older instructions tell you to query an OCSP responder. Increasingly there is no responder to query. The CA/Browser Forum made OCSP optional and CRLs mandatory as of March 2024, and Let’s Encrypt retired OCSP entirely: it stopped including OCSP URLs in new certificates in May 2025 and shut down its responders on 6 August 2025. Certificates from a growing share of CAs now carry a CRL distribution point and no OCSP address at all, which is why the CRL route above is the one worth learning.

You can confirm what your own certificate offers:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -ocsp_uri

Empty output means the certificate contains no OCSP responder URL. For a browser-based check of what your server is serving, run the domain through our free SSL Checker, which connects from outside your network and reports the certificate and chain your visitors actually receive. More background on revocation lists is in our guide to what a Certificate Revocation List is.

How to Fix NET::ERR_CERT_REVOKED as a Website Owner

Start from the fact that decides everything else: a revoked certificate cannot be un-revoked. Revocation is published, mirrored, cached and compiled into browser data sets, and no CA can reliably withdraw that signal once it has propagated. Certificate Authorities therefore treat revocation as irreversible, and the recognised way to restore trust is to issue a fresh certificate with a new serial number. Do not waste time asking your CA to reverse it.

1. Establish why it was revoked

Contact the Certificate Authority that issued the certificate and ask for the reason code, or read it from the CRL entry you checked above. The reason changes what you do next, and one answer in particular changes it a lot.

If you did not request the revocation and the CA cannot explain it, treat the possibility of a key compromise seriously and review server access logs, deployment pipelines, and any place a private key file could have been copied.

2. Generate a new private key if the key was compromised

Reusing the existing key after a key compromise defeats the entire purpose of the revocation, because the exposed key is what an attacker holds. It will also fail in practice: CAs add keys reported as compromised to a blocklist and refuse to issue any new certificate using them. Let’s Encrypt does this explicitly, blocking the key and revoking every other certificate that shares it.

Generate a fresh key and a matching CSR (Certificate Signing Request) rather than resubmitting the old one, since the old CSR carries the old public key:

openssl req -new -newkey rsa:2048 -nodes -keyout example_com.key -out example_com.csr

Keep the old key file only long enough to confirm the new certificate works, then destroy it. If the revocation reason was anything other than key compromise, reusing the key is permitted, but generating a new one costs nothing and removes the question.

3. Get the replacement issued and install it

Submit the new CSR to your CA and complete domain validation as you did originally. Where the revocation was caused by a CA-side fault, reissuance is normally free and often automatic, so check your account before buying anything.

Install the new certificate together with its intermediate chain, following the steps for your platform in our SSL certificate installation guides. Two points cause repeat failures here:

• Replace the certificate everywhere it is deployed, not only on the origin web server. Load balancers, CDNs, reverse proxies and mail or API endpoints frequently hold their own copy, and the revoked one keeps serving until it is replaced.
• Restart or reload every service that reads the certificate. A running process keeps the old certificate in memory after the file on disk has changed.

Then confirm the serial number actually changed, because serving the old file is the most common reason the error survives a reinstall:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -serial -dates

If the serial still matches the revoked one, the new certificate is not being served yet.

4. Reduce your exposure to the next one

Revocation is an emergency mechanism that the industry has quietly concluded does not work well, and the replacement strategy is to make certificates expire so quickly that revocation matters less. The CA/Browser Forum has approved a schedule that cuts the maximum lifetime of a public TLS certificate from 398 days to 200 days for certificates issued on or after 15 March 2026, then to 100 days from 15 March 2027, and to 47 days from 15 March 2029.

That cadence rules out manual renewal. Move to ACME certificate automation, which handles validation, issuance, installation and renewal on a schedule, and means that if you ever do have to replace a certificate at short notice the machinery is already in place. Where your stack supports it, OCSP stapling also lets the server present a signed freshness proof during the handshake, though its usefulness is declining as CAs retire OCSP in favour of CRLs.

Finally, keep the contact address on your CA account current and monitored. In a mass revocation the notification email is often the only warning anyone gets.

What to Do as a Website Visitor

The honest answer is that you cannot fix this one. Revocation status is a decision made by the Certificate Authority and published by it. Nothing on your computer changes it, and no browser setting suppresses it, because CRLSet checking in Chrome is not optional.

Do not click through this particular warning

Chrome will usually let you expand Advanced and proceed anyway. On most certificate errors that is a calculated risk on a site you control. Here it is a considerably worse idea, for a specific reason.

Every other code in this family can be produced by ordinary misconfiguration. This one requires a CA to have actively cancelled a certificate, and the most common reason for that is a compromised private key. Proceeding means accepting a certificate whose key may be in an attacker’s hands, on a connection that behaves identically to a genuine one. Anything you type afterwards, credentials, card numbers, session cookies, goes to whoever presented that certificate. Never proceed on a site where you sign in or pay.

The one local cause worth ruling out

There is a single realistic way this error originates on your side rather than the site’s: software that intercepts HTTPS. Antivirus products with a feature called HTTPS scanning, SSL/TLS filtering or web shield, along with corporate TLS-inspecting proxies and some VPN clients, terminate the connection themselves and re-sign it with their own certificate. Some perform their own upstream revocation check and pass a revoked verdict through. On a managed device the effect can be stronger still, because the enterprise policy mentioned earlier forces hard-fail online revocation checking on exactly this kind of locally anchored chain.

Two signs point this way: the error appears on many unrelated sites at once, or it appears on one device while other devices on the same network load the site normally. Confirm it by opening the certificate viewer and reading Issued By. If it names your security product, your employer, or a firewall vendor rather than a public CA, the interception is yours.

If it does, turn off only the HTTPS scanning component and reload, not the antivirus as a whole. On a managed device, ask IT rather than changing it yourself. On a personal device on someone else’s network, use a different network instead of installing their root certificate, since installing one lets whoever controls it read your encrypted traffic.

The quickest test of all is to load the same site on a phone using mobile data rather than Wi-Fi. If it works there, the problem is on your device or network. If the error follows you everywhere, the certificate really is revoked and only the site operator can act.

What Does Not Fix NET::ERR_CERT_REVOKED

Guides for this error tend to recycle a generic checklist written for browser problems in general. The steps below appear on many of them. None of them can affect a revocation, and knowing why saves hours:

• Correcting the date and time. The clock affects whether a certificate is inside its validity window. That is a different check with a different code, NET::ERR_CERT_DATE_INVALID (-201). A revoked certificate stays revoked at any clock setting.
• Flushing DNS or resetting TCP/IP. Revocation status is not carried in DNS and is not cached by the network stack. Chrome’s CRLSet arrives through the component updater, not through name resolution.
• Clearing the browser cache or the SSL state. Neither stores revocation decisions, and neither can change what a CA published.
• Disabling browser extensions. Extensions have no part in certificate validation. It happens below them, and no extension API can override a verifier result.
• Performing a clean boot. Starting Windows with fewer services running does not alter a certificate’s status at the CA that issued it.
• Resetting the browser. This deletes cookies, history and site settings for no benefit here. The verifier behaves identically after a reset.
• Turning off antivirus and firewall entirely. Only the HTTPS-scanning component is ever relevant, and only in the interception case described above. Disabling the whole product trades real protection for a test that a single toggle already answers.

One further piece of advice circulates for macOS and is worth calling out separately: instructions to open Keychain Access and delete root certificates such as AddTrust External CA Root or UTN DATACorp SGC. Do not do this. It dates from the AddTrust root’s expiry in May 2020, an unrelated problem that was fixed on the server side years ago, and those roots are long retired. Deleting certificates from a trust store is a destructive change that can break unrelated software, and it cannot lift a revocation in any case.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.