What key size does Firefox actually require?

For RSA and DSA, at least 2048 bits. Firefox's certificate verifier (mozilla::pkix) hard-codes a constant called MINIMUM_NON_ECC_BITS set to 2048, and it checks the public key of every certificate in the chain against it — the leaf, every intermediate, and even an OCSP responder's own certificate. Anything smaller than 2048 bits is rejected as inadequate. Elliptic-curve keys are judged on a different scale, so a 256-bit ECDSA key (P-256) sails through; the 2048 floor only applies to the older RSA/DSA family.

Why does a 1024-bit certificate fail now when it worked years ago?

Because the floor moved and 1024-bit RSA stopped being considered safe. NIST deprecated 1024-bit RSA at the end of 2013 (it's roughly 80-bit security, within reach of a well-funded attacker), and the CA/Browser Forum banned public CAs from issuing sub-2048 certificates around the same time. Firefox followed by refusing them outright. A certificate minted before those cutoffs — or by an internal CA that never got the memo — keeps working right up until a browser that enforces the floor sees it. Nothing about the cert changed; the client got stricter.

Can I just lower the minimum in about:config?

You can — the pref is security.pki.minimum_non_ecc_key_size_in_bits — but you shouldn't, and it won't help anyone but you. Lowering it tells your one Firefox to trust a key weak enough that the standards bodies stopped trusting it, and every other visitor on a normal browser still gets the error. It's a way to unblock yourself for five minutes on an internal box, not a fix. The fix is reissuing the certificate with a 2048-bit-or-larger RSA key (or an ECDSA key) and serving the full modern chain.

Views: 15

MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE: Fix

MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE: Firefox blocked a sub-2048-bit RSA key. Find the cert in 3 checks — leaf, chain, proxy. 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 refuses to load an HTTPS site and shows MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE, usually with “Warning: Potential Security Risk Ahead” and no option to click through on the strict path. The certificate isn’t expired, the name matches, the issuer might even be one you recognize — but somewhere in the chain a public key is too small, and Firefox will not negotiate a connection protected by it.

Symptoms

Firefox shows MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE on the error page or under “View Certificate.”
Chrome and Safari may show a different, more generic weak-key error on the same site — Firefox is the one that names this specific cause, which is why you searched the exact string.
openssl s_client -connect host:443 connects fine and the chain looks structurally valid — the problem is a number, not a broken link.
It hits either one specific site (that site’s cert or chain) or nearly every HTTPS site in Firefox (something local re-signing your traffic).

What This Error Actually Means

Firefox does its own certificate checking in a library called mozilla::pkix, separate from the operating system’s trust store. One of the checks it runs is a minimum public-key size, and the constant it compares against — MINIMUM_NON_ECC_BITS — is set to 2048. Every certificate in the chain gets measured: the leaf you’re connecting to, each intermediate above it, and even the certificate an OCSP responder uses to sign revocation answers. If any of them carries an RSA or DSA key smaller than 2048 bits, mozilla::pkix stops and returns MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE.

This error was deliberately carved out of the old generic SEC_ERROR_INVALID_KEY so the message would tell you why the key was rejected — not malformed, just too short. It’s a policy floor with real math behind it. A 1024-bit RSA key offers roughly 80 bits of security, which NIST retired at the end of 2013; 2048 bits gets you to about 112 bits, which is the current baseline. Firefox isn’t being fussy. It’s declining to hide a padlock behind a lock a determined attacker could pick.

The practical translation: some certificate in the path was generated with a key that stopped being acceptable years ago, and Firefox is the browser strict enough to say so by name.

Top 3 Causes

A legacy or internal CA issued the leaf with a 1024-bit (or smaller) key - Public CAs have been forbidden from issuing sub-2048 certificates since around 2014, so this almost never comes from Let’s Encrypt or DigiCert. It comes from an internal PKI, an old enterprise CA, or an embedded device — routers, printers, storage appliances, IoT gear — that shipped with a 512- or 1024-bit certificate baked in and was never rotated.
An old intermediate in the chain still has a small key - The leaf can be a perfectly modern 2048-bit cert while an intermediate above it — the one the server is stapling into the chain — is an ancient 1024-bit CA certificate. mozilla::pkix checks the whole chain, so one short link fails the lot. This is easy to miss because the leaf looks fine.
A local TLS-inspecting proxy or antivirus is re-signing with a weak key - If the error appears on nearly every HTTPS site, the certificate you’re seeing usually isn’t the site’s — it’s one minted on the fly by corporate middleware or “HTTPS scanning” antivirus that installed its own root and re-signs traffic with an undersized key. The real server is fine; the interception layer is the weak one.

Diagnose with DechoNet

SSL Check reads the certificate the server actually presents from outside your network and reports the chain. If the external chain uses 2048-bit-or-larger keys throughout, the weak key is being injected locally — a proxy or antivirus on your machine — not served by the site.
HTTP Check confirms the site responds normally to an external client, separating “the server is broken” from “Firefox on my machine won’t trust it.”
Port Check confirms 443 is reachable, ruling out a plain connectivity problem underneath the TLS layer.

Resolution Checklist

Isolate one site vs. all sites first. If it’s only one, the cert or its chain is the problem. If it’s essentially every HTTPS site in Firefox, suspect local TLS interception (corporate proxy, “HTTPS scanning” antivirus) re-signing with a weak key.
For a single site, run SSL Check and look at the key size of the leaf and every intermediate. The failing key is often an old 1024-bit intermediate, not the leaf.
Reissue the certificate with a 2048-bit-or-larger RSA key, or switch to an ECDSA key (which the 2048 floor doesn’t apply to). Regenerate the CSR — don’t reuse the old weak key.
If the weak link is an intermediate, update the chain your server sends to the current, adequately-sized intermediate from your CA. Re-run SSL Check to confirm the whole chain is clean.
For local interception, fix or disable the middleware re-signing with a small key. Lowering security.pki.minimum_non_ecc_key_size_in_bits in about:config is a downgrade, not a fix — it only masks a genuinely weak key for your one browser.
Re-run SSL Check after reissuing to confirm no certificate in the chain is under 2048 bits.

When to Escalate

Escalate to whoever runs the site’s PKI if SSL Check shows a sub-2048 key served by the origin — a device or internal CA needs a proper reissue, and there is no client-side fix for a genuinely weak certificate.
If the error appears on every HTTPS site at work, hand it to IT: their inspecting proxy or endpoint security is re-signing traffic with an undersized key, and only they can rotate it.
If a vendor’s appliance ships a 1024-bit certificate you can’t replace, escalate to the vendor for firmware that generates a modern key — a workaround pref on each user’s browser doesn’t scale and leaves the weak key in place.