Is MOZILLA_PKIX_ERROR_MITM_DETECTED an actual attack?

Usually not, but Firefox can't tell the difference, and neither should you until you check. Firefox 61 introduced this error (2018) specifically to name the case where a certificate chain fails *and* the failing root looks like local TLS interception. In the overwhelming majority of reports the interceptor is benign: antivirus 'HTTPS scanning' or a corporate proxy decrypting traffic to inspect it, re-signing every site with its own CA that Firefox doesn't trust. But the mechanism a real man-in-the-middle attacker uses is identical — sit between you and the server, present a substitute certificate. That's why the error refuses to be dismissed casually. The right response is to find out *what* is intercepting, confirm you installed it, and only then trust it.

Why does Chrome work but Firefox shows MITM_DETECTED?

Because Chrome and Edge trust the operating system's certificate store, and Firefox ships its own. When antivirus or a corporate proxy installs its interception CA into the Windows or macOS root store, Chrome silently accepts the re-signed certificates and the pages load. Firefox, using its separate NSS trust store, never saw that CA, so it can't build a valid chain — and because the pattern matches known interception, it reports MOZILLA_PKIX_ERROR_MITM_DETECTED rather than the generic SEC_ERROR_UNKNOWN_ISSUER. 'Works in Chrome' isn't proof nothing is intercepting your traffic; it's proof Chrome trusts whatever installed itself into your OS.

How do I fix it without turning off my antivirus entirely?

Enable enterprise roots. Open about:config, set security.enterprise_roots.enabled to true, and restart Firefox. That tells Firefox to also read the operating system's certificate store, where your antivirus or corporate proxy already installed its CA — so the interception chain validates and the error clears, without disabling the scanner. This only makes sense once you've confirmed the interceptor is one you actually installed. If you can't identify what's doing the interception, don't paper over the warning — that's the one scenario where MITM_DETECTED might be telling the truth.

Views: 134

MOZILLA_PKIX_ERROR_MITM_DETECTED (Firefox) Fix

MOZILLA_PKIX_ERROR_MITM_DETECTED: something is intercepting your TLS. Tell antivirus scanning from a real attack in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Firefox blocks a page with Warning: Potential Security Risk Ahead and the code MOZILLA_PKIX_ERROR_MITM_DETECTED. It reads like an accusation, and technically it is one: Firefox is telling you that the certificate on this connection wasn’t issued by a public CA it trusts, and that the substitute looks like the work of something intercepting your TLS. The server’s real certificate is fine. Something between you and the server swapped it out. The only question that matters is whether that something is your own antivirus — or an actual attacker.

Symptoms

The full-page interstitial shows MOZILLA_PKIX_ERROR_MITM_DETECTED. This is Firefox’s specific label; the generic version of the same failure is SEC_ERROR_UNKNOWN_ISSUER.
It happens on nearly every HTTPS site, not one. This is the tell. A single broken site is a server problem; an error that follows you from site to site is interception on your machine or network.
The same sites load fine in Chrome or Edge on the same computer.
The same sites load fine in Firefox on a different network (home vs. office), or on your phone over cellular.

What MITM_DETECTED Actually Means

Every HTTPS connection presents a certificate, and Firefox has to chain it — leaf → intermediate → trusted root — to a CA in its own store. When that chain fails, Firefox normally shows SEC_ERROR_UNKNOWN_ISSUER. But Firefox 61 (2018) added a check: if the connection fails and it can see that the offending root would validate if it read the operating system’s certificate store, that’s the fingerprint of local interception — some product installed its own CA into the OS and is re-signing your traffic. Firefox names that case MOZILLA_PKIX_ERROR_MITM_DETECTED so you’re not left debugging a phantom “unknown issuer.”

The word “detected” is doing a lot of work. Firefox isn’t claiming a hacker is on the line — it’s claiming the shape of the failure matches a machine-in-the-middle. Antivirus HTTPS scanning produces exactly that shape. So does a corporate inspection proxy. So does a real attacker with a rogue CA. The error is honest about the ambiguity; your job is to resolve it.

Top 3 Causes

Antivirus HTTPS/SSL scanning - The most common cause by far. Products like Avast/AVG (“Web Shield”), ESET (“SSL/TLS protocol filtering”), Kaspersky, and Bitdefender (“Scan SSL”) decrypt HTTPS to inspect it, then re-encrypt with their own CA. That CA goes into the OS store, which Chrome trusts and Firefox doesn’t — so Firefox flags the interception.
A corporate MITM / inspection proxy - On a managed network, a security appliance (Zscaler, Palo Alto, a Squid proxy with SSL bump, etc.) does the same thing at the network edge. Its root is pushed to domain-joined machines’ OS stores but not into Firefox’s NSS store, so Firefox alone objects.
An actual attacker or unexpected root - Rare, but the reason the warning exists. Malware, a rogue Wi-Fi captive portal, or a CA you didn’t knowingly install can produce this. If you can’t account for what is intercepting your traffic, treat this as the live possibility, not a formality.

Diagnose with DechoNet

SSL Check inspects the certificate the server actually serves, from our network — not through your antivirus or proxy. If SSL Check shows a valid, publicly trusted certificate for the domain while your Firefox shows a different issuer, you’ve confirmed the substitution is happening locally, on your side, not on the server.
HTTP Check confirms the site itself is reachable and healthy independent of the certificate problem, so you’re not chasing a server outage that isn’t there.

Resolution Checklist

Confirm the scope. Does it hit almost every HTTPS site, or just one? Many sites → interception on your machine or network (this guide). One site → it’s a server chain problem, and SEC_ERROR_UNKNOWN_ISSUER is the closer fit.
Identify the interceptor before trusting it. Click Advanced on the Firefox warning and read the issuer name — it usually says the product outright (e.g. “Avast Web/Mail Shield Root”, “ESET SSL Filter CA”, “Kaspersky Anti-Virus Personal Root”). That name tells you what installed itself.
Cross-check with SSL Check. If our SSL Check shows a normal public CA (Let’s Encrypt, DigiCert, Google Trust Services) for the same domain, the issuer name your Firefox sees is the interceptor — proof it’s local.
If it’s your antivirus and you recognize it, either turn off its HTTPS/SSL scanning feature, or keep it and let Firefox trust it: about:config → set security.enterprise_roots.enabled to true → restart. Firefox will then read the OS store where the AV root already lives.
If it’s a corporate proxy, the enterprise root has to be delivered to Firefox by IT (enterprise policy or security.enterprise_roots.enabled). This is an endpoint-management task, not a per-machine one.
If you cannot identify what is intercepting — no antivirus you installed, not a managed network — stop and treat it as a possible attack. Disconnect from the network, scan for malware, and check the OS certificate store for CAs you don’t recognize.

When to Escalate

If SSL Check shows a clean public certificate but Firefox still reports MITM_DETECTED after you’ve ruled out antivirus and enterprise roots, inspect the OS root store directly (certmgr.msc on Windows, Keychain Access on macOS) for an unfamiliar CA — that’s where an unwanted interceptor hides.
On a corporate network, escalate to IT rather than clicking through. If inspection is policy, they distribute the root the right way; clicking “Accept the Risk” per-site trains you to ignore the one control designed to catch a real intercept.
If the interceptor turns out to be something you never installed, treat it as a compromise, not a certificate nuisance — the entire point of this error is to make that case visible.