# ERR_BAD_SSL_CLIENT_AUTH_CERT: client certificate rejected

> ERR_BAD_SSL_CLIENT_AUTH_CERT means a site requiring client certificates (mTLS) rejected yours or got none. Causes for users and server fixes.

Source: https://ssl.sh/errors/err-bad-ssl-client-auth-cert/
Last updated: 2026-11-10

**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](https://ssl.sh/tools/ssl-checker/) (`curl ssl.sh/example.com`), then see which client CAs the server asks for:

```bash
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:

```bash
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](https://ssl.sh/tools/certificate-decoder/).

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Chrome / Edge | "This site can't provide a secure connection" with "example.com didn't accept your login certificate, or one may not have been provided. ERR_BAD_SSL_CLIENT_AUTH_CERT" |
| Firefox | "Secure Connection Failed" with `SSL_ERROR_BAD_CERT_ALERT` or `SSL_ERROR_HANDSHAKE_FAILURE_ALERT` |
| Safari | "Safari can't open the page" or a certificate selection prompt |
| curl | `alert bad certificate` or `alert certificate required` (TLS 1.3 alert 116) |

## 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.**

```nginx
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](https://ssl.sh/learn/mtls/).