How to Fix SEC_ERROR_UNKNOWN_ISSUER in Firefox

What SEC_ERROR_UNKNOWN_ISSUER actually means

Firefox raises SEC_ERROR_UNKNOWN_ISSUER when it cannot build a trust path from your site's certificate up to a root certificate it already trusts. Every publicly trusted certificate is signed by an intermediate CA, which is in turn signed by a root CA baked into the browser. Firefox trusts the root. It does not automatically know about the intermediate unless your server hands it over during the TLS handshake.

The important Firefox-specific detail: Firefox ships its own trust store (built on Mozilla's NSS library) and largely ignores the operating system's certificate store. That's why a site can work in Chrome and Edge on Windows but fail in Firefox on the same machine. Chrome and Edge lean on the Windows store, which may have cached the intermediate from a previous visit; Firefox will not. So a 'works everywhere except Firefox' report is a strong signal that the chain is incomplete.

The usual cause: a missing intermediate certificate

When a CA issues your certificate, they give you at least two files: your leaf (server) certificate and one or more intermediate certificates. If you install only the leaf on your web server, browsers that already cached the intermediate keep working, and Firefox, starting cold, throws SEC_ERROR_UNKNOWN_ISSUER because the issuer of your leaf is 'unknown' to it.

The fix is to serve the leaf and the intermediates together, in order, so Firefox can walk the chain to a trusted root. This bundle is what most tools call the fullchain.

Diagnose it in two minutes

Confirm the chain is the problem before touching config. From any machine with OpenSSL, run: openssl s_client -connect example.com:443 -servername example.com. Read the 'Certificate chain' block at the top. If it lists only your leaf (position 0) and no intermediate, that's your bug. A healthy chain shows the leaf, then one or more intermediates, ending near the root.

For a friendlier view, our free SSL checker reports exactly which certificates the server presents and flags a broken or incomplete chain. Both approaches beat guessing from the browser alone, because Firefox's warning page doesn't tell you which link is missing.

Fix it on the server

The repair is to point your server at the full chain file instead of the bare certificate. If you use Let's Encrypt via Certbot, the file you want is fullchain.pem (leaf + intermediate), not cert.pem. In nginx, set ssl_certificate to the fullchain file. In Apache, either use SSLCertificateFile with the full chain (2.4.8+) or set SSLCertificateChainFile to the intermediate bundle on older versions.

After deploying, reload the service and re-test with openssl s_client or the SSL checker. Firefox caches trust decisions, so also do a hard refresh or test in a fresh private window to avoid confusing yourself with stale state.

• nginx: ssl_certificate /path/fullchain.pem; (leaf + intermediates in one file)
• Apache 2.4.8+: SSLCertificateFile pointing at the full chain
• Older Apache: SSLCertificateChainFile pointing at the intermediate bundle
• Load balancers/CDNs: paste the intermediate into the 'certificate chain' field, not just the leaf

When it's the client, not the server

If the chain is provably complete but one user still sees SEC_ERROR_UNKNOWN_ISSUER, the problem has moved to their machine. The most common cause is TLS inspection: corporate firewalls, some antivirus products (with HTTPS scanning enabled), and monitoring tools re-sign traffic with their own root CA. Firefox doesn't trust that private root by default, so it reports an unknown issuer.

On managed Windows or macOS fleets, the enterprise root often lives in the OS store, which Firefox ignores. The fix is to let Firefox read enterprise roots: set security.enterprise_roots.enabled to true in about:config, or push it via policy. Also rule out a badly wrong system clock, if the date is off by years, chain validation fails for a different reason but the symptoms overlap. Only import a root certificate manually if you know exactly who issued it; a warning you don't understand is not an invitation to click through.

Stop it from coming back

Chain problems love to reappear: a certificate renews, an automation script grabs cert.pem instead of fullchain.pem, or a CA rotates its intermediate and your pinned bundle goes stale. Because Firefox is the strictest common browser about chains, it's often the first place you'll hear about it, from a customer, not a dashboard.

That's the gap continuous monitoring closes. VigilDog checks your live certificate chain the way a cold browser would, not just the leaf's expiry date, and alerts you when an intermediate goes missing or a renewal ships an incomplete bundle, before Firefox users start filing tickets.