SEC_ERROR_INADEQUATE_KEY_USAGE in Firefox: How to Fix It

SEC_ERROR_INADEQUATE_KEY_USAGE is an NSS error code (-8102, SEC_ERROR_BASE + 90) that Firefox shows when a certificate in the server's chain carries a keyUsage extension that does not permit the role the certificate plays. It is a certificate-verification failure during the TLS handshake, not a DNS, network or HTTP problem. Firefox's verifier (mozilla::pkix) raises it in three situations:

• Server (leaf) certificate: the keyUsage extension is present but contains none of digitalSignature, keyEncipherment or keyAgreement. Firefox tries all three and fails only if every one is missing.
• Intermediate or root used as an issuer: its keyUsage lacks keyCertSign, so it is not allowed to sign certificates.
• Malformed extension: an empty bit string or non-zero padding bits in the DER encoding.

A certificate without any keyUsage extension is not restricted and does not cause this error. A missing serverAuth in extendedKeyUsage is a different failure, reported as SEC_ERROR_INADEQUATE_CERT_TYPE. One more detail: if the server certificate is self-signed and fails this way, Firefox reports MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT instead.

Firefox does not let you add an exception for this error: it is not in the group of overridable certificate errors (unknown issuer, expired, name mismatch). That is deliberate, because the certificate is structurally unfit for its job, not merely untrusted.

For server certificates Firefox is more lenient than Chrome: a keyEncipherment-only RSA certificate passes in Firefox but fails in Chrome 124 and later with ERR_SSL_KEY_USAGE_INCOMPATIBLE. A leaf with only dataEncipherment or nonRepudiation fails in both. For issuing CAs the rule is the same in both browsers: if a CA certificate has a keyUsage extension, it must assert keyCertSign. In practice the error usually points to a private CA: OpenSSL configs copied from old tutorials, appliance-generated certificates, or test PKI scripts.

Firefox validates the certificate of whatever terminates TLS, so behind Cloudflare's proxy your origin certificate is not the one it rejects. The check that applies: on nginx, HAProxy or a load balancer, Firefox receives the whole chain file in the TLS-terminating configuration, and an old internal intermediate without keyCertSign left in that file is a frequent cause.

1. Dump every certificate the server sends.

   openssl s_client -connect app.internal:443 -servername app.internal -showcerts </dev/null 2>/dev/null \
     | awk '/BEGIN CERT/{n++} {print > ("cert" n ".pem")}'
   for f in cert*.pem; do echo "== $f"; openssl x509 -in "$f" -noout -subject -ext keyUsage,basicConstraints; done

   The leaf (cert1.pem) needs Digital Signature and, for RSA, preferably also Key Encipherment. Every certificate with CA:TRUE that has a key usage line needs Certificate Sign.
2. Fix the leaf profile. Reissue with:

   keyUsage = critical, digitalSignature, keyEncipherment
   extendedKeyUsage = serverAuth

   For an ECDSA key, digitalSignature alone is the correct set.
3. Fix the CA profile if an issuer is the culprit. An intermediate needs keyUsage = critical, keyCertSign, cRLSign and basicConstraints = critical, CA:TRUE. Changing a CA certificate means re-signing it and then reissuing or at least re-chaining every server certificate under it.
4. Public CA certificates: these are issued with standard profiles, so suspect the deployment: a wrong file in the chain, an old intermediate left in the bundle, or an inspection device in front of the server.
5. Reload and retest: nginx -t && systemctl reload nginx, then repeat step 1.

Extensions are covered by the CA signature, so there is no way to patch them into an existing certificate; only a reissue changes them.

• Only at work or school: a TLS-inspection proxy is probably generating the certificate. Report the exact code to IT.
• Antivirus HTTPS scanning: turn off encrypted-connection scanning and reload. If the error goes away, update or reconfigure the antivirus.
• Your own device (router, NAS, camera, lab server): regenerate or upload a correct certificate as described above.
• Public site that fails for everyone: nothing on your side will fix it. Contact the site owner; trying another browser may load the page, but the certificate stays defective.

Clearing Firefox's cache or history does not help, because the certificate is delivered in each handshake. The system clock plays no role in this error.

Re-run the openssl loop from the owner steps and confirm the leaf shows Digital Signature and each CA shows Certificate Sign. Then reload the page in Firefox with a fresh tab. For an outside view of the chain, SANs, expiry and protocol support, use the enterno.io SSL checker.

• ERR_SSL_KEY_USAGE_INCOMPATIBLE: the Chrome counterpart
• SEC_ERROR_CA_CERT_INVALID: an issuer that is not a valid CA
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
• SEC_ERROR_UNKNOWN_ISSUER: chain not trusted
• Incomplete certificate chain