Is SSL_ERROR_BAD_CERT_ALERT a problem with the website's certificate?

No — and this is the most important thing to get straight, because it sends everyone down the wrong path. Firefox's own wording is 'SSL peer cannot verify your certificate,' and the operative word is *your*. This error is not about the server's certificate. It's about a certificate *you* presented. On a mutual-TLS connection, the server asks the browser for a client certificate; when Firefox sends one the server won't accept — or the handshake needs one it couldn't supply — the server replies with a fatal bad_certificate alert (TLS alert code 42, RFC 5246 §7.2.2, carried into TLS 1.3 by RFC 8446 §6.2), and Firefox surfaces that received alert as SSL_ERROR_BAD_CERT_ALERT. Reissuing or fixing the *server's* certificate does nothing here, because the server's certificate was never the thing in question. The rejected certificate is the client one.

How is this different from SSL_ERROR_HANDSHAKE_FAILURE_ALERT?

They're two different alerts the server can send about client authentication, and which one you get narrows the cause. SSL_ERROR_HANDSHAKE_FAILURE_ALERT is alert code 40 (handshake_failure): the server couldn't negotiate acceptable parameters at all — often because it required a client certificate and Firefox sent *none*, so the handshake dies generically before authentication. SSL_ERROR_BAD_CERT_ALERT is alert code 42 (bad_certificate): Firefox *did* send a client certificate and the server evaluated it and found it unacceptable — expired, signed by a CA the server doesn't trust, revoked, or otherwise not what the endpoint wants. There's an even narrower cousin, SSL_ERROR_UNKNOWN_CA_ALERT (alert 48), which is specifically 'I don't trust the CA that signed your client cert.' All three are the server's verdict delivered to Firefox as an alert; 42 is the one that says a certificate was presented and rejected.

It only fails on one corporate, government, or banking site. Why?

Because that one site requires mutual TLS and the others don't. The overwhelming majority of the web never asks your browser for a client certificate, so every ordinary site loads fine. Corporate intranets, government portals, banking back-ends, partner APIs, and admin panels frequently require a client certificate or smartcard, and that's exactly where SSL_ERROR_BAD_CERT_ALERT shows up. If it started recently on a site that used to work, something changed on the client side: the client certificate expired, a smartcard was removed, a Firefox profile was reset, or the certificate you're presenting was renewed under a CA the server hasn't been told to trust yet. An external TLS check confirms the server's own certificate and handshake are healthy, which isolates the fault to the client certificate you're sending.

Views: 9

SSL_ERROR_BAD_CERT_ALERT in Firefox: Fix

SSL_ERROR_BAD_CERT_ALERT: the server rejected your client certificate, not its own. Check the cert, its CA, and expiry. 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 the page with SSL_ERROR_BAD_CERT_ALERT and the message Secure Connection Failed — SSL peer cannot verify your certificate. Almost everyone reads that as a problem with the site’s certificate and starts checking the server’s expiry and chain. That’s the wrong tree. Read the message literally: your certificate. The server asked Firefox for a client certificate, Firefox presented one, and the server rejected it. This is a mutual-TLS failure, and the certificate under suspicion is the one on your side.

Symptoms

Firefox shows Secure Connection Failed with the code SSL_ERROR_BAD_CERT_ALERT and the text SSL peer cannot verify your certificate.
There is no “Add Exception” / “Accept the Risk” override — this isn’t an untrusted server certificate warning.
It hits one specific site, portal, or API — typically corporate, government, banking, or an internal admin panel — while the rest of the web is fine.
The same endpoint may work in Chrome or Edge if a client certificate is already selected there, making it look like a Firefox-only bug.
It started right after a client certificate expired or was renewed, a smartcard was removed, or a Firefox profile was reset.

What This Error Actually Means

A TLS handshake can include client authentication. The server sends a CertificateRequest, and the browser answers with a client certificate to prove who it is — this is mutual TLS. The server then validates that client certificate: is it within its validity dates, signed by a CA the server is configured to trust, not revoked, and structurally sound? If the answer is no, the server sends a fatal bad_certificate alert — TLS alert code 42, defined in RFC 5246 §7.2.2: “A certificate was corrupt, contained signatures that did not verify correctly, etc.” — and TLS 1.3 keeps the same alert in RFC 8446 §6.2. Firefox surfaces the received alert as SSL_ERROR_BAD_CERT_ALERT.

The direction is the whole diagnosis. This alert was sent by the server, about the certificate you presented. It is not Firefox distrusting the server, and it is not the server’s own certificate being bad. It’s the server saying “the ID you handed me isn’t one I’ll accept.” So the entire investigation moves to the client certificate: which one Firefox is sending, whether it’s valid, and whether the server was ever configured to trust the CA that issued it. Firefox has long tracked how confusing this error is — the raw text names your certificate but gives no hint as to why it was refused (Bugzilla 1255049).

Top 3 Causes

The client certificate is expired, revoked, or structurally invalid. The endpoint requires mutual TLS and Firefox is presenting a certificate the server won’t take — past its notAfter date, revoked, or malformed. bad_certificate (alert 42) is precisely the “a certificate was corrupt or its signatures didn’t verify” case. This is the classic one-site failure that appears the moment a client certificate lapses or a smartcard is pulled.
The client certificate is signed by a CA the server doesn’t trust. Your certificate is valid, but the server was never told to trust its issuing CA — or it was renewed under a new intermediate the server’s trust store hasn’t been updated to include. This is the boundary with SSL_ERROR_UNKNOWN_CA_ALERT (alert 48); some servers send the narrower “unknown CA” alert, others send the general bad_certificate. Either way the fix is on the server’s client-CA trust configuration, not on the client.
The wrong certificate is being presented, or none Firefox can match. Firefox holds several client certificates and offers one the endpoint doesn’t accept, or a required smartcard PKCS#11 module isn’t loaded so the right certificate is never presented. The server sees an identity it can’t validate and rejects it. This is why the error can appear right after a profile reset or a certificate reinstall.

Diagnose with DechoNet

SSL Check runs a full TLS handshake against the host from outside your network and reports the server’s own certificate, chain, and negotiated protocol. If it comes back healthy, you’ve proven the server side is fine — its certificate is valid and it can complete a handshake — so your failure is entirely about the client certificate your Firefox is sending. That’s the fork that stops you from wasting time on the server’s expiry and chain.
HTTP Check fetches the site from outside your browser. Because our checks don’t present a client certificate, a mutual-TLS endpoint will typically refuse them too — but the SSL check still confirms whether the server’s own certificate and TLS stack are sound, which is exactly what you need to isolate the problem to client authentication.

Resolution Checklist

Confirm the server side is healthy first. Run an external SSL Check. A valid server certificate and clean handshake mean the problem is the client certificate you’re presenting — stop looking at the server’s expiry.
Check your client certificate’s validity. In Firefox, Settings → Privacy & Security → Certificates → View Certificates → Your Certificates. Confirm the certificate for this endpoint exists, is within its dates, and hasn’t been superseded by a renewal you didn’t import.
Verify the smartcard / PKCS#11 module is loaded. If the endpoint uses a smartcard, make sure the security device is present and the module is loaded (Settings → Privacy & Security → Security Devices), so Firefox can actually present the right certificate.
Ask whether the server trusts your issuing CA. If your certificate is valid but was issued (or renewed) under a CA or intermediate the server hasn’t been configured to trust, the server rejects it. This is a server-side trust-store fix, coordinated with whoever administers the endpoint.
Don’t reissue the server certificate. It was never the problem. The alert is about the client certificate; a new server certificate changes nothing.
Isolate client vs. server. External SSL check clean but Firefox still fails → it’s your client certificate. External SSL check also unhealthy → that’s a different problem entirely (the server’s own certificate), not this one.

When to Escalate

If your client certificate is valid and current but the endpoint still rejects it, escalate to whoever administers that service: only they can confirm which client CA the endpoint trusts and whether your certificate’s issuer is in that list. Renewals under a new intermediate are a common trigger.
If you don’t have a client certificate for an endpoint that clearly requires one, that’s an enrollment task for the service’s administrators — they issue and register the client certificate or smartcard, and they decide which identities the endpoint accepts.