How is this different from ERR_CERT_AUTHORITY_INVALID?

Direction. Every ERR_CERT_* error — AUTHORITY_INVALID, DATE_INVALID, COMMON_NAME_INVALID — is about the *server's* certificate: the browser doesn't trust what the site presented. ERR_BAD_SSL_CLIENT_AUTH_CERT is the mirror image: the server asked *you* for a certificate, and the one your browser sent (or didn't send) got rejected. This is mutual TLS. The server proves itself to you as usual, then turns around and demands you prove yourself back. So the fix lives in a different place: not the site's cert chain, but the client certificate sitting in your OS or browser store. If you're the site operator, it's not your server cert that's broken — it's the client-auth trust config or the certificate on the visitor's machine.

Why can't I click through this warning like other certificate errors?

Because there's nothing to click through. A server-cert warning is the browser second-guessing a connection it *could* still make — so Chrome lets you accept the risk and proceed. A client-auth failure is different: the TLS handshake itself did not complete. The server required a valid client certificate, your side couldn't supply one it accepts, and the connection was terminated at the protocol level before any HTTP happened. There's no page to bypass to, because no secure channel was ever established. The only path forward is presenting a client certificate the server actually trusts.

It happens on every site, not just one. What does that mean?

One site failing means that specific site requires mTLS and your certificate isn't accepted there — normal for an admin panel, a bank portal, or a zero-trust gateway. Every site failing points somewhere else: local TLS interception. Antivirus 'HTTPS scanning' and corporate proxies sit in the middle of your connections, and a buggy or misconfigured one can mangle the client-authentication step for everything. A stale or duplicate certificate in your OS store does the same. When the error is universal, suspect your own machine — security software or the certificate store — not a hundred websites simultaneously deciding to demand a cert.

Views: 27

ERR_BAD_SSL_CLIENT_AUTH_CERT: Client Cert Rejected

ERR_BAD_SSL_CLIENT_AUTH_CERT means a site's mTLS check rejected your client certificate — missing, expired, or untrusted. 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

Chrome refuses to load the site and shows ERR_BAD_SSL_CLIENT_AUTH_CERT. This is not the usual “your connection is not private” warning about the server’s certificate. The server asked you for a certificate — this site uses mutual TLS — and the client certificate your browser offered was missing, expired, or not one the server trusts. The handshake died on the client-authentication step.

Symptoms

The error appears only on specific sites: an internal admin panel, a bank or government portal, a Cloudflare-protected endpoint with mTLS rules, a Kubernetes dashboard, a VPN or zero-trust gateway.
There is no “Proceed anyway” link — unlike server-certificate warnings, you cannot click through.
The same URL works from a colleague’s machine that has the right certificate installed.
Or the reverse: it suddenly breaks on every HTTPS site, which points at local interception rather than the sites themselves.
curl to the same host fails with a TLS alert about a required or unacceptable certificate.

What This Error Actually Means

In a normal TLS handshake, the server sends its certificate and the client verifies it. Mutual TLS adds a second leg. Per the handshake spec (TLS 1.3, RFC 8446 §4.3.2), the server can send a CertificateRequest message asking the client to authenticate too. Now you have to present a certificate, and the server validates it against the set of certificate authorities it’s willing to accept. If your browser sends nothing, sends an expired cert, sends one signed by a CA the server doesn’t recognize, or sends one without its matching private key, the server aborts the handshake with a fatal alert. Chrome surfaces that as ERR_BAD_SSL_CLIENT_AUTH_CERT.

The critical distinction — the one that decides where you look — is whose certificate failed. Every ERR_CERT_* error is a complaint about the server’s certificate. This one is a complaint about yours. The server’s own certificate can be flawless; the site can be perfectly healthy for the rest of the world; and you still get this error because the credential the site wants from you isn’t there or isn’t acceptable.

That’s also why there’s no bypass. A server-cert warning means “I can connect but I’m not sure I should.” A client-auth failure means the secure channel was never built — the connection was cut mid-handshake. There’s no insecure version to fall back to.

Top 3 Causes

No client certificate, or the wrong one selected - The site requires mTLS and your machine has no matching certificate installed, or you have several and the browser offered one the server doesn’t accept. Corporate laptops often carry multiple client certs, and Chrome will happily send the wrong one.
The client certificate is expired, revoked, or missing its private key - Client certificates expire like any other. A cert imported without its private key (a .cer instead of a .pfx/.p12) looks installed but can’t complete the handshake. A revoked cert is rejected outright by the server.
Local TLS interception breaking client auth - Antivirus HTTPS scanning or a corporate proxy terminates and re-establishes your TLS connections. If it doesn’t forward client certificates correctly — many don’t — it silently breaks mTLS for everything. This is the usual explanation when the error hits every site at once.

Diagnose with DechoNet

SSL Check to confirm the server side is healthy from the outside. DechoNet inspects the site’s own certificate and chain independently of your machine, so a clean result isolates the problem to the client-authentication step — which lives entirely in your OS or browser certificate store, not on the server. If the SSL Check comes back normal but you still get ERR_BAD_SSL_CLIENT_AUTH_CERT locally, that gap is the whole diagnosis: the server’s cert is fine, so the failure is the certificate you are (or aren’t) presenting. It also rules out a mislabeled server-cert problem hiding behind the client-auth error.

Resolution Checklist

Confirm the site actually requires mTLS. If it loads on another machine that has a specific certificate installed, mutual TLS is the reason — you need that certificate, not a browser fix.
Check whether any client certificate is installed for this site, and that it hasn’t expired. Open the OS/browser certificate store and verify the validity dates.
Make sure the certificate includes its private key. A cert imported from a .cer/.pem without the key can’t authenticate; re-import from the .pfx/.p12 you were issued.
Verify the issuing CA matches what the server trusts. The server only accepts client certs from specific authorities; a valid cert from the wrong CA is still rejected. Ask the site operator which CA they require.
Remove stale or duplicate client certificates so Chrome stops offering the wrong one during the handshake.
If the error hits every HTTPS site, disable antivirus “HTTPS/SSL scanning” and any TLS-intercepting proxy, then retry. If that fixes it, the interceptor was breaking client auth.

When to Escalate

If you’re a visitor and you have no client certificate at all, this is not something you can fix from the browser — the site owner has to issue you one or drop the mTLS requirement. Contact them.
If you run the site and legitimate users are hitting this, check the trust configuration for client certificates: which CA bundle validates them, whether client auth is set to required versus optional, and whether a recent change tightened the accepted issuers. That’s a server-side config problem, not a user error.