The site works in Chrome but Firefox shows SEC_ERROR_UNKNOWN_ISSUER. Why?

You're almost certainly missing an intermediate certificate, and the two browsers handle that gap differently. When a server sends the leaf certificate but not the intermediate that links it to a trusted root, Chrome on many platforms performs AIA fetching — it reads the 'CA Issuers' URL inside the certificate and downloads the missing intermediate on the fly, so the page loads. Firefox does not do AIA fetching (Bugzilla 399324 has been open since 2007). It relies on intermediates it already has: its own preloaded set from the CCADB, plus any it cached from earlier connections. If the missing intermediate isn't in that set, Firefox can't build the chain and shows SEC_ERROR_UNKNOWN_ISSUER. The site isn't 'fine in Chrome' — it's misconfigured, and Chrome is quietly covering for it.

I get SEC_ERROR_UNKNOWN_ISSUER on almost every HTTPS site, not just one.

That's a different cause. When the error appears everywhere, something on your machine is intercepting TLS and re-signing it with a certificate authority Firefox doesn't trust — usually antivirus 'HTTPS scanning' / 'web shield', or a corporate proxy. Firefox often reports this specific case as MOZILLA_PKIX_ERROR_MITM_DETECTED. The fix is to turn off the antivirus HTTPS-inspection feature, or let Firefox trust the enterprise root by enabling 'security.enterprise_roots.enabled' so it reads the OS certificate store.

Why does Firefox fail when the certificate is already in the Windows certificate store?

Because Firefox ships its own root store (NSS) and, by default, does not consult the Windows one. A root you imported into Windows — a corporate CA, a self-signed dev root, an antivirus CA — is trusted by Chrome and Edge, which use the OS store, but invisible to Firefox. Either import the root into Firefox's own certificate manager, or set 'security.enterprise_roots.enabled' to true so Firefox also reads enterprise roots from the OS.

Views: 103

SEC_ERROR_UNKNOWN_ISSUER (Firefox) Fix

SEC_ERROR_UNKNOWN_ISSUER: Firefox can't chain your certificate to a trusted root. Check for a missing intermediate or antivirus HTTPS scanning. 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 shows Warning: Potential Security Risk Ahead with the error code SEC_ERROR_UNKNOWN_ISSUER. The certificate the server presented is not broken — it’s that Firefox can’t trace it back to a certificate authority in its trust store. Every valid certificate has to chain, leaf → intermediate → trusted root. Firefox got the leaf but couldn’t complete that chain, so it refuses to trust the connection. The question is where the chain broke: on the server (a missing intermediate), on your machine (something re-signing your traffic), or in Firefox’s trust store (a root it doesn’t have).

Symptoms

The full-page interstitial reads SEC_ERROR_UNKNOWN_ISSUER. Chrome and Edge phrase the same underlying condition as NET::ERR_CERT_AUTHORITY_INVALID.
On antivirus/proxy interception, Firefox may instead show the more specific MOZILLA_PKIX_ERROR_MITM_DETECTED.
If it’s one site: it often loads fine in Chrome or on your phone but fails in Firefox — the signature of a missing intermediate.
If it’s every site: the error follows you, not the site — the signature of local TLS interception.

Top 3 Causes

The server is missing its intermediate certificate - The most common single-site cause. The server sends only the leaf certificate and omits the intermediate that links it to the root. Firefox doesn’t fetch missing intermediates over the network (no AIA fetching), so unless it already has that intermediate preloaded or cached, the chain can’t be built. Chrome hides the same misconfiguration by fetching the intermediate, which is why “works in Chrome” is not proof the server is set up correctly.
Antivirus or a proxy is intercepting TLS - When the error appears across many sites, an antivirus product doing HTTPS/SSL scanning (or a corporate MITM proxy) is decrypting your traffic and re-signing it with its own CA. Firefox, using its own root store, doesn’t trust that CA and reports SEC_ERROR_UNKNOWN_ISSUER — or MOZILLA_PKIX_ERROR_MITM_DETECTED when it recognizes the pattern.
A self-signed or private root not in Firefox’s store - Internal tools, dev environments, and appliances often use a self-signed certificate or a private CA. Because Firefox maintains its own NSS trust store separate from the operating system, importing the root into Windows or macOS is not enough — Firefox still won’t trust it until the root is in Firefox’s store or enterprise-roots reading is enabled.

Diagnose with DechoNet

SSL Check shows the exact chain the server sends — leaf, and whether the intermediate is present. If the chain is incomplete here (leaf without intermediate), you’ve confirmed cause #1, and the fix is on the server, not in Firefox.
HTTP Check confirms the endpoint responds once TLS is set aside, useful for separating a certificate-chain problem from an actual connectivity failure.

Resolution Checklist

Determine the scope first: does the error hit one site or many? One site → chain problem on the server. Many sites → interception on your machine. This single question routes you to the right fix.
For one site, inspect the served chain: openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN -showcerts. If you see only the leaf (one CERTIFICATE block) and no intermediate, the server is misconfigured. Reinstall the certificate with the full chain (leaf + intermediate bundle) — most CAs provide a “fullchain” file for exactly this.
Re-run SSL Check and confirm the intermediate now appears in the chain. Don’t rely on “it loads in Chrome” — Chrome’s AIA fetching masks the missing intermediate that Firefox correctly rejects.
For many sites, disable your antivirus’s HTTPS/SSL scanning (often called “web shield,” “encrypted connection scanning,” or “scan SSL”). If the error clears, that was it. If you must keep it on, let Firefox trust the enterprise root: open about:config, set security.enterprise_roots.enabled to true, and restart.
For an internal or self-signed certificate, import the root explicitly into Firefox: Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import. Importing it into the OS store alone won’t reach Firefox.
If it’s a genuinely untrusted or expired root on the server side, the real fix is to reissue from a publicly trusted CA — clicking through the warning trains users to ignore a real security control.

When to Escalate

If SSL Check shows a complete chain but Firefox still fails, check the system clock and the root’s own validity — an expired or distrusted root CA (browsers periodically remove CAs from the trust store) produces this error even with a correctly assembled chain, and the fix is a new certificate from a currently trusted CA.
If the interception is a corporate proxy you don’t control, the enterprise root must be distributed to Firefox by IT (via security.enterprise_roots.enabled or an enterprise policy). That’s an endpoint-management task, not something to fix per-machine.
If you can’t tell whether the extra CA in the chain is legitimate antivirus or an actual attacker, treat it as suspicious until proven otherwise — MOZILLA_PKIX_ERROR_MITM_DETECTED exists precisely because that distinction matters.