ERR_BAD_SSL_CLIENT_AUTH_CERT: client certificate rejected

ERR_BAD_SSL_CLIENT_AUTH_CERT means the website requires you to prove your identity with a client certificate, and the certificate Chrome offered was not accepted (or none was offered). This happens on sites using mutual TLS (mTLS): company portals, government systems, some banking and API endpoints.

Is it the site or your device?

Usually it is the certificate on your device, or your account's entitlement to the site. First confirm the server's own certificate is fine with the SSL checker (curl ssl.sh/example.com), then see which client CAs the server asks for:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | sed -n '/Acceptable client certificate CA names/,/Requested Signature/p'

If the server lists acceptable client CAs and your certificate is not from one of them, you have the wrong certificate. If the server lists none, or the error started for every user at once, the server's configuration changed.

Causes

1. No client certificate available

The certificate lives on a smart card or USB token that is not plugged in, its middleware is not running, or it was never installed on this computer or browser profile.

2. Expired or revoked client certificate

Client certificates expire like server certificates. Check the validity in your operating system's certificate manager (Windows certmgr.msc > Personal; macOS Keychain Access > My Certificates).

3. Wrong certificate selected

With several personal certificates installed, Chrome may have picked or remembered the wrong one. Restart the browser and choose again.

4. Server trusts a different client CA

The server's trusted client CA file (ssl_client_certificate in Nginx) does not include the CA that issued your certificate, often after a CA rotation. Test from the command line:

curl -v --cert client.pem --key client.key https://example.com/ -o /dev/null

5. Missing clientAuth EKU or wrong key usage

A certificate without clientAuth in its extended key usage is rejected by servers that check it. Decode it with the certificate decoder.

What it looks like in each browser

How site owners fix it

Trusting the correct client CA, and issuing client certificates with the clientAuth EKU, fixes most server-side cases.

1. Point the server at the right client CA bundle.

ssl_client_certificate /etc/nginx/ssl/client-ca.pem;
ssl_verify_client on;
ssl_verify_depth 2;

2. Use a dedicated client CA whose certificates include extendedKeyUsage=clientAuth; do not rely on public server certificates for client authentication.

3. Give users a clear path. Log $ssl_client_verify and $ssl_client_s_dn in Nginx so support can see why a handshake failed, and consider ssl_verify_client optional with an application-level error page instead of a bare TLS failure.

4. Check the public side with curl ssl.sh/example.com after changes. Background: mTLS.