# ERR_BAD_SSL_CLIENT_AUTH_CERT：网站不接受你的客户端证书

> ERR_BAD_SSL_CLIENT_AUTH_CERT 表示要求客户端证书（mTLS）的网站拒绝了你的证书，或者没收到证书。用户侧原因和服务器修法。

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

**ERR_BAD_SSL_CLIENT_AUTH_CERT 的意思是：网站要求你用客户端证书证明身份，而 Chrome 提供的证书没被接受（或者没有提供）。** 这出现在使用双向 TLS（mTLS）的网站上：企业门户、政务系统、部分企业网银以及 API 接口。

## 先判断是网站的问题还是你电脑的问题

问题通常出在你设备上的客户端证书，或者你的账号没有访问权限。先用 [SSL 检测](https://ssl.sh/zh/tools/ssl-checker/)（`curl ssl.sh/example.com`）确认服务器自己的证书没问题，再看服务器要求哪些客户端 CA：

```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'
```

服务器列出了可接受的客户端 CA，而你的证书不是它们签发的，就是证书不对。服务器没列出任何 CA，或者所有用户同时开始报错，就是服务器配置变了。

## 原因

最常见的情况是浏览器找不到可用的客户端证书，比如 U 盾没插。

### 1. 没有可用的客户端证书

证书存放在智能卡或 USB Key（俗称“U 盾”“Key”）里，但没插上、驱动或证书助手没启动，或者证书从没装到这台电脑、这个浏览器配置文件里。很多政务和企业系统要求先安装 CA 机构提供的证书客户端。

### 2. 客户端证书过期或被吊销

客户端证书和服务器证书一样会过期。在系统证书管理器里看有效期（Windows 运行 `certmgr.msc` → 个人；macOS 打开钥匙串访问 → 我的证书）。

### 3. 选错了证书

装了好几张个人证书时，Chrome 可能选了或记住了错误的那张。重启浏览器重新选择。

### 4. 服务器信任的是另一个客户端 CA

服务器的客户端 CA 文件（Nginx 的 `ssl_client_certificate`）里没有签发你证书的 CA，常见于 CA 更换之后。用命令行测试：

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

### 5. 缺 clientAuth 扩展密钥用途

扩展密钥用途里没有 `clientAuth` 的证书，会被检查 EKU 的服务器拒绝。用 [证书解析](https://ssl.sh/zh/tools/certificate-decoder/) 查看。

## 在各浏览器/系统上的样子

Chrome 内核的浏览器显示 ERR_BAD_SSL_CLIENT_AUTH_CERT，Firefox 和 curl 显示的是服务器发回的 TLS 告警名称。

| 浏览器 | 显示内容 |
|---|---|
| Chrome / Edge / 360 / QQ 浏览器 | “此网站无法提供安全连接”，说明网站不接受您的登录证书或您未提供，代码 `ERR_BAD_SSL_CLIENT_AUTH_CERT` |
| Firefox | “建立安全连接失败”，代码 `SSL_ERROR_BAD_CERT_ALERT` 或 `SSL_ERROR_HANDSHAKE_FAILURE_ALERT` |
| Safari | 无法打开网页，或弹出证书选择框 |
| curl | `alert bad certificate` 或 `alert certificate required`（TLS 1.3 告警 116） |

## 站长怎么修

服务器信任的客户端 CA 必须和用户证书的签发者一致；握手失败时，还要给用户一条看得懂的提示。

**1. 让服务器指向正确的客户端 CA 文件。**

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

**2. 使用专门的客户端 CA**，签发的证书带 `extendedKeyUsage=clientAuth`；不要依赖公开的服务器证书做客户端认证。

**3. 给用户留一条明白的路。** 在 Nginx 日志里记录 `$ssl_client_verify` 和 `$ssl_client_s_dn`，方便客服排查握手为什么失败；也可以用 `ssl_verify_client optional`，由应用返回一个说明清楚的错误页，而不是让用户看到光秃秃的 TLS 失败。

**4. 改完从外部检查。** 运行 `curl ssl.sh/example.com`。原理见 [mTLS 双向认证](https://ssl.sh/zh/learn/mtls/)。