Chrome calls it "Your connection is not private", with NET::ERR_CERT_AUTHORITY_INVALID underneath. Firefox shows "Warning: Potential Security Risk Ahead" with SEC_ERROR_UNKNOWN_ISSUER, or a page titled "Software is Preventing Firefox From Safely Connecting to This Site" with MOZILLA_PKIX_ERROR_MITM_DETECTED. All of them say the same thing: your browser got a certificate from an issuer it does not trust.
Where it appears tells you most of the story. On one site, that site's certificate is usually the problem. On every HTTPS site at once, from your search engine to your bank, something on your side is replacing the certificates: an antivirus, a company network, or software you never chose. This guide shows how to name it and what to do about each one.
It is also one of the most searched browser errors. Keyword Planner counts about 33,100 searches a month worldwide for "err_cert_authority_invalid". The Firefox code for interception is far rarer, but it is growing: "mozilla_pkix_error_mitm_detected" rose from 260 searches in October 2025 to 1,300 in September 2026.
What does the error mean?
The Chromium source code defines it in one line: the server "responded with a certificate that is signed by an authority" Chrome does not trust. The same file lists three possible reasons. Someone swapped in a fake one, the site uses a real issuer that Chrome does not know, or the site signed its own.
The codes next to it point elsewhere, which helps to tell them apart. NET::ERR_CERT_DATE_INVALID means the certificate looks expired or not yet valid "by our clock", and a wrong clock on your computer is one of the causes it lists. NET::ERR_CERT_COMMON_NAME_INVALID means the name on the certificate does not match the site. The file lists a Wi-Fi network's login page among its causes.
Why does it hit every site at once?
Because one thing sits in front of all of them. An interceptor ends your encrypted connection at itself, reads the traffic, opens its own connection to the site, and hands your browser a fresh certificate that it signed itself. Company networks do this to enforce policy, many antivirus suites do it to scan for malware, and some unwanted software does it to watch or change what you see.
Your browser
checks the certificate
Interceptor
decrypts, re-signs with its own CA
The real site
its true certificate stops here
When your browser trusts the interceptor's root, nothing shows at all. The CERT Coordination Center described this in 2015 for software built on the Komodia library, such as the Superfish adware, which installed its own root certificate so that it could intercept all web traffic "without raising any flags for the end-user". The warning appears in the other case, when your browser does not trust the interceptor. So the error means two things at once: something is intercepting, and your browser has not been told to accept it.
How do I find out what is intercepting?
Read the certificate before you change anything. In Chrome or Edge, click the warning text or "Not secure" in the address bar and open the certificate details. In Firefox, choose Advanced on the warning page and view the certificate. The Issued by line names the interceptor.
What the Issued by line tells you, and where the fix is
| What you see | What is happening | Where the fix is |
|---|---|---|
| Your company's name, or a security gateway product | Company HTTPS inspection | Your IT team |
| An antivirus or security suite | The suite scans HTTPS with its own root | The suite's HTTPS scanning setting |
| Errors only on one Wi-Fi network, often ERR_CERT_COMMON_NAME_INVALID | The network's login page is answering first | Sign in through the network's portal |
| A name you do not know, on every network | Software on your computer | Remove the software, then its root |
| The site's usual authority, with ERR_CERT_DATE_INVALID | Your clock, or an expired certificate | Set the clock to update automatically |
| Only one site fails | That site's own certificate | Nothing on your side; try later |
Chromium net_error_list.h, Chrome Help, ESET KB3126, CERT/CC VU#529496, read October 23, 2026
What if it is my antivirus?
This is the most common cause on a home computer. Security suites call the feature by different names: ESET calls it SSL/TLS protocol filtering, Avast's help pages call it HTTPS scanning, and Kaspersky's speak of scanning encrypted connections. All of them decrypt HTTPS so that they can scan it, and all of them need their own root certificate trusted by your browser.
ESET's support article explains what goes wrong. The root certificate used for filtering "may not be properly installed" during installation. HTTPS sites then fail to load or show certificate errors. Its fix is to turn SSL/TLS protocol filtering off and on again, which "often resolves the issue by triggering the correct import and registration of the root certificate". In ESET for Windows, press F5 for Advanced setup, open Protections, then SSL/TLS.
You can also turn the scanning off. ESET is clear about the trade-off: with filtering off, "threats delivered through encrypted communications may not be detected at the network level". Re-importing the root keeps the scanning and ends the warnings.
What if it is my employer?
On a managed work computer, HTTPS inspection is usually deliberate. IT installs the company's root certificate on each machine, and the browsers then accept the re-signed certificates without a warning. Chrome trusts root certificates added to the operating system, its help pages say. On Windows, the Chromium FAQ lists the stores it reads, including Trusted Root Certification Authorities for the user (certmgr.msc) and for the machine (certlm.msc).
Firefox used to be the exception, because it keeps its own certificate list. Since Firefox 120, released on November 21, 2023, it imports user-added root certificates from the operating system by default on Windows, macOS and Android. The switch sits under Settings, Privacy & Security, Certificates. Firefox also turns it on by itself when it detects a middleman, its own source shows.
So on a work computer, a warning means the company root is missing from this device or this browser. Send IT the issuer name and a screenshot. Do not click through as a habit, because a warning that should not be there is exactly what inspection setups are supposed to surface.
What if it is something I did not install?
Then treat it as a security problem. On a personal computer with no company network and no HTTPS scanning, an interceptor you cannot name is software you need to remove. The Komodia case shows why the order matters. CERT/CC warned that "uninstalling affected applications is not sufficient", because the root certificates stay behind, so they must be removed separately.
- Remove the software. Run a full malware scan, and check your installed programs and browser extensions for anything you do not recognize.
- Remove its root certificate. On Windows, open certmgr.msc and look under Trusted Root Certification Authorities. The Chromium FAQ notes that roots added by a user or a company show up under the Registry, Group Policy or Enterprise stores, while Microsoft's own list shows as Third-Party. On a Mac, open Keychain Access and look for an unknown certificate set to Always Trust.
- Check the proxy settings too. Software that intercepts traffic often sets a system proxy as well. Our guide on proxy settings that keep turning back on covers finding it.
- Change your passwords from a clean device, if the interceptor was active while you signed in anywhere.
Do proxies cause certificate errors?
An ordinary proxy does not. When your browser asks a proxy for an HTTPS site, it sends a CONNECT request. RFC 9110 says the proxy then establishes a tunnel and restricts itself "to blind forwarding of data, in both directions, until the tunnel is closed". The encryption runs from your browser to the site, so the site's own certificate reaches you unchanged. Our guide to the tunnel a proxy opens covers that step.
Only a proxy built to inspect traffic, like a company gateway, changes them. If a proxy you added brings certificate warnings, it is doing more than forwarding, and you should find out why before you trust it. You can check any proxy on a site you know: through a plain tunnel, the Issued by line shows the site's usual authority.
The same inspection breaks command-line tools, which fail with an "unknown authority" message instead of a warning page. Our guide to git, npm, pip and Docker behind a proxy covers that side. If you use proxies for work, our residential proxies cost $0.50/GB for one GB, falling to $0.44/GB at 2,000 GB+.
Is it safe to click through the warning?
Only when you can name the issuer and know it should be there, for example when IT confirms that the company inspection is the cause. Clicking through tells the browser to accept a certificate it could not verify. From then on it cannot confirm who is on the other end, and whoever holds that certificate can read what you send. Never do it on a login, banking or payment page, or on a machine where you cannot say what the issuer is.
What we could not check
- We did not reproduce an interception on any computer or network. The facts on this page come from Chromium's and Firefox's source, Chrome's help, Firefox's release notes, ESET's support article and CERT/CC, read on October 23, 2026.
- Kaspersky's and Avast's own help pages could not be read through our server, because of a robots rule and a script-only page. We name their features from their article titles only.
- Browsers and security suites change how they handle certificates. This page is due for a check by January 23, 2027.
Sources
- Chromium source, net/base/net_error_list.h (the three certificate codes), and the Chrome Root Store FAQ (the Windows and macOS stores Chrome reads), read October 23, 2026.
- Chrome Help, Check if a site's connection is secure, read October 23, 2026.
- Firefox source: the error text in certError.ftl, the defaults in StaticPrefList.yaml and firefox.js, and the MITM handling in NetErrorParent.sys.mjs, read October 23, 2026. The Firefox 120 release notes, November 21, 2023.
- ESET, KB3126: Manage SSL/TLS protocol filtering in ESET Windows applications, read October 23, 2026.
- CERT/CC, Vulnerability Note VU#529496, February 19, 2015, revised March 17, 2015.
- RFC 9110 section 9.3.6, June 2022, for CONNECT.
- Google Keyword Planner, worldwide monthly searches, read October 23, 2026.
