What's the difference between MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT and SEC_ERROR_UNKNOWN_ISSUER?

They describe two different broken chains, and the fix differs. SEC_ERROR_UNKNOWN_ISSUER means the certificate *was* signed by some other authority — Firefox just doesn't have that authority in its trust store (a private CA, or a missing intermediate you forgot to install). MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT means there is no other authority: the certificate's Issuer equals its Subject — it signed itself. One says 'I don't know who vouched for this'; the other says 'nobody did.' If you see self-signed, adding an intermediate won't help, because there's no chain to complete.

The certificate works in Chrome but not Firefox. Why only Firefox?

Because Firefox ships its own root store (NSS) and, by default, ignores the operating system's certificate store. Chrome and Edge on Windows read the Windows store, so a cert you (or your antivirus, or your company) imported into Windows is trusted there — and invisible to Firefox. That's why the exact same self-signed or private cert throws in Firefox alone. To make Firefox trust it, import the certificate into Firefox's own Authorities tab, or set `security.enterprise_roots.enabled` to `true` so Firefox reads the OS store.

Is it ever safe to just click through the warning?

On a machine you control, talking to a device you control — your own router, NAS, or a staging box on your LAN — clicking Advanced and accepting the risk is a reasonable, informed choice. On the public internet it isn't. A self-signed certificate on a real website means the connection is encrypted but unauthenticated: nothing proves you're talking to the real server rather than someone sitting in the middle. Encryption without identity is exactly the gap TLS exists to close, so on anything public the answer is to fix the certificate, not bypass the warning.

MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT: Fix in Firefox

Problem

Firefox stops you with “Warning: Potential Security Risk Ahead,” and behind the Advanced button sits the error code MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT and the line “The certificate is not trusted because it is self-signed.” The site loads fine in Chrome. It may even load fine in Firefox on another machine. This is Firefox telling you the certificate it received signed itself — there’s no chain back to any authority it trusts.

Symptoms

The error page shows MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, not SEC_ERROR_UNKNOWN_ISSUER or SEC_ERROR_EXPIRED_CERTIFICATE.
The same URL opens without warning in Chrome or Edge on the same computer.
It fails everywhere in Firefox for a public site, or only on one machine for an internal one.
openssl s_client -connect host:443 -servername host reports verify error:num=18:self signed certificate and a chain exactly one certificate deep.
Common on staging servers, home routers, NAS boxes, printers, and appliances that ship a default certificate.

What This Error Actually Means

Every certificate names an Issuer (who vouched for it) and a Subject (who it’s for). In a normal chain those differ: your leaf certificate’s Issuer is an intermediate CA, whose Issuer is a root, whose certificate is in Firefox’s trust store. Firefox walks that chain up to a root it trusts, and the padlock appears.

A self-signed certificate is a chain of one. Its Issuer and Subject are identical — it vouches for itself. There’s nothing above it to walk to, and it isn’t a trusted root, so Firefox’s certificate verifier (mozilla::pkix) stops and reports the specific condition it found: the certificate is its own issuer. That specificity is the useful part. It’s not saying “I couldn’t find the intermediate” (that would be SEC_ERROR_UNKNOWN_ISSUER) — it’s saying there is no intermediate to find. The cert is the whole chain.

The one wrinkle that makes this a Firefox-only surprise: Firefox keeps its own root store and, out of the box, doesn’t consult the OS certificate store. Import a cert into Windows and Chrome trusts it; Firefox won’t notice until you either import it into Firefox directly or flip security.enterprise_roots.enabled. So “works in Chrome, fails in Firefox” isn’t a Firefox bug — it’s two different trust stores disagreeing about the same cert.

Top 3 Causes

The server genuinely serves a self-signed certificate. A dev/staging box with an openssl-generated cert, or an appliance (router, NAS, iDRAC, printer) presenting its factory default. This is by far the most common. The tell: openssl s_client shows verify error:num=18 and a one-deep chain, and it fails in Firefox everywhere.
You deployed the wrong certificate. You meant to install a CA-issued leaf plus its intermediate, but what’s actually live is a private CA’s self-signed root, or a regenerated placeholder cert that never got replaced. The tell: the served Subject/Issuer is your internal CA name, not your hostname.
Something on the client is intercepting TLS. A corporate proxy or antivirus doing HTTPS inspection can swap in its own self-signed certificate. The tell: it reproduces only on one machine or one network, and other devices load the site cleanly. (Firefox often flags known interception as MOZILLA_PKIX_ERROR_MITM_DETECTED instead — but not always.)

Diagnose with DechoNet

SSL Check fetches the certificate the host actually serves and shows the chain — whether the leaf is self-signed (Issuer equals Subject, chain length one) or signed by an authority Firefox simply doesn’t know. That single distinction tells you whether you need a real certificate or just a missing intermediate.

Resolution Checklist

Confirm the code is SELF_SIGNED_CERT, not UNKNOWN_ISSUER — the first needs a real certificate, the second needs a missing intermediate. Don’t fix the wrong one.
Run SSL Check on the host and read the chain: length one with matching Issuer/Subject confirms self-signed.
Public site: replace the self-signed cert with a CA-issued one. A free ACME certificate from Let’s Encrypt takes minutes and ends the error for every browser at once. Self-signed doesn’t belong on the public internet.
Internal/dev host you control: either issue the cert from a private CA and distribute that CA’s root to your machines, or import the specific certificate into Firefox’s Certificate Manager → Authorities. For fleet-managed Windows, security.enterprise_roots.enabled = true lets Firefox read the OS store.
If it reproduces on only one machine, inspect antivirus/proxy TLS inspection before touching the server — the server may be fine.
Verify from the command line: openssl s_client -connect host:443 -servername host — verify error:num=18:self signed certificate confirms it at the source.

When to Escalate

If SSL Check shows a legitimate CA-issued chain but Firefox alone still reports self-signed, the server isn’t the problem — a client-side interception layer is rewriting the certificate, and the fix belongs on the endpoint or in the proxy config, not the web server.

Check your own domain now

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