NET::ERR_SSL_CLIENT_AUTH_FAILED 是 Chrome 系浏览器在 TLS 握手阶段返回的明确错误，通常和站点启用了双向 TLS（mTLS）认证有关。单向 TLS 只有客户端校验服务器证书，而 mTLS 要求服务器同时校验客户端证书。很多团队在源站开启了客户端证书校验，接入 CDN 后没有同步调整 CDN 的回源策略，或者反向过来：CDN 边缘开启了双向认证，源站却没有准备对应的 CA 链，导致请求在某一跳被拒绝。排查这个错误，核心就是确认证书信任链在浏览器、CDN 边缘节点、源站三个位置是否完整。
一、TLS客户端认证的握手流程与错误触发点
标准的单向 TLS 握手中，客户端校验服务器的数字证书，确认自己连接的是可信服务器。双向 TLS 在此基础上增加了一步：服务器在发送 ServerHello 之后，会向客户端发送 CertificateRequest 消息，要求客户端提交自己的 X.509 证书。客户端收到请求后，如果本地安装了由服务器信任的 CA 签发的证书，就会把证书链随下一个握手消息发送过去；如果客户端没有证书、用户主动取消选择，或者提交的证书不被信任，服务器或 CDN 边缘节点就会中止握手，浏览器最终显示为 NET::ERR_SSL_CLIENT_AUTH_FAILED。
当流量经过 CDN 时，整个连接被拆成两段：第一段是浏览器到 CDN 边缘节点，第二段是 CDN 边缘节点回源到源站。这两段都可以独立配置双向认证，而且互不影响。也就是说，可能源站要求客户端证书，但 CDN 回源时没有携带证书，源站返回 handshake failure，CDN 再把这个失败转成 502 或直接透传给用户；也可能 CDN 边缘节点自己开启了双向认证，但客户端根本没有安装证书，此时浏览器端直接报错，源站甚至没有收到请求。所以在排查时必须先把两段链路分开验证，不能只盯着源站日志。
可以用 openssl 命令直接模拟带客户端证书的握手，观察在哪个节点中断：
openssl s_client -connect origin.ipipp.com:443 -servername origin.ipipp.com -cert ./client.crt -key ./client.key -CAfile ./ca.crt -state
如果这条命令能够完成握手并输出证书信息，说明源站双向认证配置正常，问题大概率出在 CDN 回源配置；如果握手失败，则需要检查源站的证书配置、客户端证书是否有效、CA 链是否完整。
二、CDN接入后最常见的三类配置错误
第一类是源站开启了双向认证，但 CDN 回源时没有透传客户端证书。这在团队从直连源站切换到 CDN 后非常常见。源站 Nginx 配置了 ssl_verify_client on，直连时用户浏览器会正常弹出证书选择框，但接入 CDN 后，用户在浏览器侧只与 CDN 边缘完成单向 TLS，证书不会自动转发到源站。CDN 的回源请求本身没有携带客户端证书，源站拒绝握手，用户看到的就是 NET::ERR_SSL_CLIENT_AUTH_FAILED 或者 CDN 返回的 502。解决办法是在 CDN 回源配置中上传同一个客户端证书，并开启回源双向认证，让 CDN 代替客户端向源站出示证书。
第二类是 CDN 边缘节点开启了双向认证，但证书信任链没有正确下发到边缘节点。CDN 控制台通常要求上传客户端证书对应的 CA 证书，而不是只上传客户端证书本身。如果只上传了客户端公钥，或者 CA 链不完整，边缘节点无法验证用户提交的客户端证书，浏览器就会在证书选择后仍然报错。另外，用户在浏览器中取消证书选择、或者操作系统/浏览器没有导入客户端证书，也会直接触发这个错误。此时需要确认客户端证书在用户设备上安装正确，并且证书未过期、未被吊销。
第三类是证书信任链不完整或 CA 证书过期。内部 PKI 签发的客户端证书通常包含根 CA 和中间 CA，如果服务器只信任了中间 CA，没有包含完整的根证书链，openssl verify 会报 unable to get issuer certificate。源站 Nginx 的 ssl_client_certificate 需要包含完整的 CA 链文件，CDN 边缘节点上传的 CA 文件也必须完整。部分团队会忽略中间证书的有效期，导致已经过期的中间证书让整条信任链失效。
此外，还需要检查 CDN 回源协议是否保持 HTTPS。如果回源协议不小心改成 HTTP，双向认证自然无从谈起，源站看到的是一段没有 TLS 的明文请求，日志中会出现 non-SSL traffic 之类的提示。回源端口、回源 SNI、回源 HOST 设置错误也可能导致握手失败，这些基础配置要和源站实际监听保持一致。
三、Nginx与CDN双向认证配置示例
源站 Nginx 开启客户端证书校验的典型配置如下。这里 ssl_client_certificate 指向的是签发客户端证书的 CA 链文件，必须包含根证书和所有中间证书；ssl_verify_depth 控制最大验证深度，一般设置为 2 即可应对两级 CA 结构。
server {
listen 443 ssl;
server_name origin.ipipp.com;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
ssl_verify_client on;
ssl_client_certificate /etc/nginx/ssl/client_ca.crt;
ssl_verify_depth 2;
location / {
proxy_pass http://backend;
}
}
如果只希望对部分敏感路径启用双向认证，可以将 ssl_verify_client 设置为 optional，再在 location 中判断客户端证书校验结果。这样普通页面仍然可以匿名访问，只有管理后台等路径强制要求证书。
ssl_verify_client optional;
ssl_client_certificate /etc/nginx/ssl/client_ca.crt;
location /admin {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
}
在 CDN 控制台上，需要找到回源配置或 HTTPS 配置中的双向认证相关选项。不同厂商的命名可能略有差异，比如“客户端证书回源”“回源双向认证”“自定义回源证书”。开启后上传与源站相同的客户端证书文件和私钥，部分平台还需要上传 CA 链。配置完成后务必使用 curl 模拟带证书请求测试：
curl -v --cert ./client.crt --key ./client.key --cacert ./ca.crt https://cdn.ipipp.com/admin
如果返回 200 说明链路打通；如果返回 403 或握手失败，则要根据 CDN 回源日志和源站 Nginx 错误日志继续定位。注意客户端证书私钥在 CDN 平台和源站之间传输时要走加密通道，并且只在测试阶段使用临时证书，正式环境建议使用受控 PKI 签发的专用证书。
四、不中断服务的排查与上线建议
遇到这个错误后，第一步永远是绕过 CDN 直连源站测试。可以修改本地 hosts 文件或者使用 curl --resolve 参数，让请求直接打到源站 IP，同时携带客户端证书。如果直连成功，可以确认源站双向认证本身没有问题，排查重点转向 CDN 回源配置；如果直连也失败，则需要先修复源站证书链、证书有效期或 Nginx 配置。
如果确认源站正常而 CDN 异常，重点检查 CDN 回源配置中是否真正开启了客户端证书透传。部分 CDN 默认只做单向 TLS 回源，需要手动绑定客户端证书并开启双向认证回源。还要确认回源 SNI 和回源 HOST 是否正确，源站是否限制只允许特定 SNI 的 TLS 握手。有些源站配置了严格 SNI 检查，CDN 回源使用的 SNI 与源站证书不匹配时也会出现证书相关错误。
双向认证不建议直接在正式环境全量开启。应该先在测试域名或特定路径灰度验证，观察回源日志、证书校验失败率、浏览器端错误率等指标，确认没有普通用户被误拦截。对于只需要保护内部系统或 API 的场景，可以考虑在 CDN 边缘保持单向 HTTPS，同时配合源站 IP 白名单、私有网络回源、应用层 JWT 认证等方式替代 mTLS。传输层客户端证书虽然安全性高，但证书管理和多级 CDN 透传复杂度也很高，要根据实际业务需求权衡。
总结来说，NET::ERR_SSL_CLIENT_AUTH_FAILED 的本质是 TLS 双向认证中证书信任链在某一跳断裂，而不是简单的过期问题。把浏览器到 CDN、CDN 到源站两段链路分开验证，逐项核对证书文件、CA 链、回源协议与控制台配置，通常能快速定位并恢复服务。
NET::ERR_SSL_CLIENT_AUTH_FAILEDCDNmTLS修改时间：2026-10-03 14:33:58