The page is the one everyone recognises: a red or grey warning, "Your connection is not private" in Chrome or "Warning: Potential Security Risk Ahead" in Firefox, and a code underneath. NET::ERR_CERT_AUTHORITY_INVALID. SEC_ERROR_UNKNOWN_ISSUER. MOZILLA_PKIX_ERROR_MITM_DETECTED. On a single site, once, it is usually the site's own certificate expiring or misconfigured. When it appears on every HTTPS site at once, from your search engine to your bank, it means something different and more important: something between you and the web is opening your encrypted connections, reading them, and sealing them back up with a certificate of its own.
That "something" has three common identities, and the browser cannot tell them apart for you, but the certificate can. This is the browser-side companion to the certificate errors developers meet on the command line, where git, npm, pip, and Docker all fail with an "unknown authority" message for the exact same reason. The tools report it as a build error; the browser reports it as a warning page. The cause, and the fix, are the same, and they start with reading the certificate.
What the error actually means
Every HTTPS site proves its identity with a certificate, signed by a certificate authority your browser already trusts. Your browser carries a list of those authorities, and it checks every certificate against the list. When the signature traces back to an authority on the list, the padlock closes silently. When it does not, you get the warning.
An intercepting layer breaks that chain deliberately. Instead of letting your browser talk to the site directly, it terminates the connection at itself, decrypts it, inspects or logs it, opens its own connection onward to the site, and then presents your browser a freshly minted certificate signed by its own authority. If your browser trusts that authority, everything looks normal and the interception is invisible. If it does not, every site fails the check, because every site's certificate now comes from the same unrecognised signer.
Your browser
checks the certificate
Interceptor
decrypts, re-signs with its own CA
The real site
its true certificate stops here
That is the whole mechanism, and it explains the single most useful fact about this error: a warning on one site is about that site, and a warning on all of them is about your side of the connection.
Read the certificate first
Before changing anything, name the interceptor. In Chrome or Edge, click the "Not secure" text or the warning, choose the certificate details, and read the Issued by or Issued to line. In Firefox, click the warning, then View Certificate, and read the Issued By section. That name is the answer.
| What "Issued by" says | What is intercepting you | Where the fix is |
|---|---|---|
| Your company's name, or a product like Zscaler, Netskope, Palo Alto, Fortinet, Cisco Umbrella | Corporate SSL inspection | IT, and the browser's trust store |
| An antivirus brand: Kaspersky, Avast, AVG, ESET, Bitdefender, BullGuard | The antivirus is scanning HTTPS | The antivirus settings |
| A name you do not recognise, on a personal machine with no corporate proxy | Adware or malware, or a parental-control app | Removal and a scan |
| The real site's own name, but with a date problem (ERR_CERT_DATE_INVALID) | Not interception at all | Your system clock |
The last row is worth separating out immediately, because it is the one case that has nothing to do with a proxy. NET::ERR_CERT_DATE_INVALID with an otherwise valid issuer usually means your computer's clock is wrong, which makes every certificate look expired or not-yet-valid. Set the date and time to update automatically, and the warnings clear. Everything else on the list is interception, and the rest of this guide is about telling the three kinds apart.
If it is your employer
On a managed work computer, corporate SSL inspection is deliberate and normal. IT runs a proxy that decrypts your traffic to enforce policy and scan for threats, and to make it invisible they install the company's certificate authority in the machine's trust store when they set the computer up. Chrome and Edge read that store, so they usually trust it and show no warning at all.
Two situations produce a warning anyway.
Firefox, because it keeps its own store. Firefox does not automatically trust authorities installed in the operating system; it carries its own list. On a corporate machine that means Firefox alone throws MOZILLA_PKIX_ERROR_MITM_DETECTED while Chrome is fine. The intended fix is to let Firefox read the system store: open a new tab, go to about:config, accept the warning, search for security.enterprise_roots.enabled, and set it to true. On a properly managed machine this is often already enforced by policy; if it is not and you are unsure, this is IT's call to make, not yours to force.
A genuinely missing or misconfigured certificate. If Chrome and Edge also warn on the work network, the company authority is not in the store, or the inspection is misconfigured, and only IT can fix it. Report it with the issuer name and a screenshot. Do not train yourself to click past it, because a warning that appears when it should not is exactly the signal SSL inspection is supposed to preserve.
If it is your antivirus
This is the most common cause on a personal computer that is not malware, and it surprises people because the culprit is software they installed for protection. Many security suites include a feature variously called HTTPS scanning, encrypted connection scanning, SSL/TLS inspection, or a web shield, and it works by doing exactly what a corporate proxy does: intercepting HTTPS and re-signing it with the product's own authority. When that authority is not fully installed, or a browser update changes how trust is checked, every HTTPS site warns.
If the Issued by line names Kaspersky, Avast, AVG, ESET, Bitdefender, or a similar product, open that product's settings and find the HTTPS or encrypted-connection scanning option. You can either turn it off, which stops the interception and clears the warnings, or let the product reinstall its certificate, which most offer a button for. Turning the feature off is the cleaner choice for most home users: the security benefit of scanning inside HTTPS is debated, and the cost is a program sitting in the middle of every secure connection you make.
If it is something you did not install
Here the tone changes, because an interceptor you cannot account for is a serious finding. On a personal machine with no corporate proxy and no antivirus HTTPS scanning, a certificate signed by an authority you do not recognise means a program installed its own root certificate on your computer so it could read your encrypted traffic. That is how adware injects ads into pages, how some "free" tools monetise, and how credential-stealing malware reads logins. The warning is your browser catching it.
Confirm and clean, in this order:
- Find the root. On Windows, open Certificate Manager (
certmgr.msc), expand Trusted Root Certification Authorities, and look for an issuer that is not Microsoft, a well-known public authority, your operating system vendor, or a product you recognise. On a Mac, open Keychain Access, choose the System keychain, and look under Certificates for an unfamiliar root marked as trusted. An unknown root with a recent installation date, matching the Issued by name from the warning, is your interceptor. - Scan. Run a full malware scan, and a second-opinion scanner such as Malwarebytes or AdwCleaner, because the program that installed the certificate is what you actually need to remove.
- Remove the certificate once the software is gone.
- Check for the wider pattern. Software that installs a certificate to read your traffic often also sets a proxy to route it. Our guide on proxy settings that keep turning back on covers finding that, and it carries the password advice that applies here: if an interceptor you did not install was reading your HTTPS traffic, treat the passwords you used while it was active as exposed, and change them from a clean device.
Why the bypass is the wrong instinct
Chrome lets you continue past the warning with a Proceed link, and on the warning page you can even type thisisunsafe to dismiss it. Firefox has Accept the Risk and Continue. All of them do the same thing: they tell the browser to accept a certificate it could not verify, for that site, which means it can no longer confirm who is on the other end.
Sometimes that is a considered choice. On a work machine where you know the corporate proxy is the cause and IT confirms it, proceeding is a stopgap while they fix the trust store. But as a reflex it is dangerous, because the warning exists precisely for the case you cannot see: an interceptor you did not authorise, reading a page you are about to type a password into. Never proceed on a login, payment, or work page, and never on a machine where you cannot name the issuer from the certificate. The disciplined response to an unexplained warning is to find the cause, which the certificate hands you, not to click it away.
The honest note about proxies
A proxy company should be clear about this, because the error has the word certificate in it and people reasonably wonder whether the proxy they added is at fault. A proxy you configure to route your traffic, the ordinary kind, does not cause this error. For an HTTPS site it opens a blind tunnel with a CONNECT request and relays the encrypted bytes without looking at them, so the site's own certificate reaches your browser untouched and validates exactly as it would without the proxy. Our guide on the tunnel a proxy opens covers that mechanism. Certificate errors come only from an intercepting proxy that decrypts and re-signs, which is a deliberate inspection setup that a plain proxy is not.
So if a proxy you added starts producing certificate warnings, it is doing more than proxying, and that is worth understanding before you trust it with anything. The proxies we run tunnel HTTPS; they do not sit inside it. The one place a certificate does enter a normal proxy setup is on the command line, where a corporate inspecting proxy makes git, npm, pip, and Docker fail with the same "unknown authority" message, and the fix there is the same as the browser fix here: trust the authority that is actually doing the inspecting, once you have confirmed you know what it is.
Sort it in one look
- On every HTTPS site, not one? It is interception, not a broken site.
- Click the padlock or warning, view the certificate, read Issued by.
- Your company or an inspection product: it is the corporate proxy. Firefox needs
security.enterprise_roots.enabled; Chrome and Edge use the system store; a warning there is IT's to fix. - An antivirus brand: turn off its HTTPS scanning, or let it reinstall its certificate.
- A name you do not know, with no corporate proxy: find the root in the certificate store, scan, remove it, and change passwords from a clean device.
- A date problem with a real issuer: fix your clock.
The warning looks like an obstacle. It is actually your browser doing the one job it exists to do, telling you that the private connection you expected is not private, and naming, in the certificate, exactly who is standing in the middle.