Go tls.Config.ClientAuth 为什么没有触发客户端证书校验怎样定位

我排查 Go 双向 TLS 时遇到过一个很容易误判的现象：服务端明明配置了 ClientCAs，客户端没有证书，连接却仍然成功。问题通常不在证书文件，而在 ClientAuth 仍是默认策略，或者只“请求”证书却没有“要求并校验”。

定位这类问题要先看策略，再看证书供给，最后读握手后的 ConnectionState。ClientAuth 默认是 tls.NoClientCert；真正要求客户端提供并通过服务端信任池校验，应使用 tls.RequireAndVerifyClientCert。

先把 ClientAuth 五种策略放回同一张表

ClientAuth 描述的是服务端对客户端证书的策略，不是客户端信任服务端证书的开关。先把“是否请求”“是否必须提供”“是否校验”分开，很多“没有触发校验”的误会就会消失。

如果目标是 mTLS，服务端通常需要把策略和信任池同时配置好：

serverConfig := &tls.Config{
    // 服务端证书用于证明服务端身份。
    Certificates: []tls.Certificate{serverCert},
    // 必须提供客户端证书，并且证书链要通过 ClientCAs 校验。
    ClientAuth: tls.RequireAndVerifyClientCert,
    // 这里只放服务端信任的客户端 CA，不是客户端证书本身。
    ClientCAs: clientCAPool,
}

只填写 ClientCAs 而不改变 ClientAuth，并不会自动把普通 TLS 变成双向认证；零值配置仍然表示不要求客户端证书。

核对客户端供证与服务端信任池

第二个常见误区是把两端的证书配置混在一起。客户端要通过 Certificates 提供自己的证书链和私钥；服务端用 ClientCAs 决定哪些 CA 可以签发受信任的客户端证书。

func clientTLSConfig(certFile, keyFile string, serverCAPool *x509.CertPool) (*tls.Config, error) {
    // 读取客户端证书和私钥，供服务端的 CertificateRequest 使用。
    cert, err := tls.LoadX509KeyPair(certFile, keyFile)
    if err != nil {
        // 保留原始错误，便于区分文件、格式和权限问题。
        return nil, err
    }
    return &tls.Config{
        // Certificates 是客户端身份，不是服务端的根证书池。
        Certificates: []tls.Certificate{cert},
        // RootCAs 只负责验证服务端证书，与 ClientCAs 属于不同方向。
        RootCAs: serverCAPool,
    }, nil
}

因此可以按下面的方向快速排除：

• 客户端没有 Certificates，且服务端是 RequireAndVerifyClientCert：握手应失败，重点看客户端是否加载证书。
• 客户端有证书但服务端的 ClientCAs 不包含签发链：握手会因验证失败而失败，重点核对 CA 池和中间证书。
• 服务端是 RequestClientCert 或 VerifyClientCertIfGiven：没有客户端证书时连接仍可能成功，这是策略本身允许的结果。

从握手错误和 ConnectionState 读证据

“连接成功”只能说明 TLS 握手完成，不能单独证明客户端证书已被强制验证。服务端处理完握手后，读取 PeerCertificates 和 VerifiedChains 更有信息量：

state := tlsConn.ConnectionState()
// PeerCertificates 表示对端发送的证书，服务端可能为空。
peerCount := len(state.PeerCertificates)
// VerifiedChains 表示服务端完成的客户端证书链验证结果。
verifiedCount := len(state.VerifiedChains)
fmt.Printf("peer=%d verified=%d resumed=%v\n", peerCount, verifiedCount, state.DidResume)

在服务端，PeerCertificates 为空通常说明客户端没有发送证书，或者当前策略没有要求它发送；VerifiedChains 为空则不能当作“证书已经被信任”的证据。若使用 RequireAndVerifyClientCert，证书缺失或验证失败应在握手阶段直接得到错误，而不是等业务层自行猜测。

排查时建议把错误按边界记录下来：tls: client didn't provide a certificate 更接近“客户端未供证”；证书链验证失败则应继续核对客户端证书用途、签发链和服务端 ClientCAs。不要为了让连接先跑通而长期启用 RequestClientCert 或跳过校验。

迁移到可回归的双向 TLS 配置

我会把下面四项写进配置评审和回归用例，而不是只检查服务端是否能启动：

1. 明确认证目标：单向 TLS 不设置客户端证书要求；mTLS 明确使用 RequireAndVerifyClientCert，或说明为何采用可选策略。
2. 分别检查两端：客户端检查 Certificates，服务端检查 ClientAuth 与 ClientCAs，不要用 RootCAs 代替 ClientCAs。
3. 覆盖三种用例：无客户端证书、由错误 CA 签发的证书、正确证书链。前两种在强制策略下都应失败。
4. 在服务端日志中记录证书数量和握手错误，但不要记录私钥、完整证书内容或可用于复用的敏感材料。

这样处理后，“ClientAuth 没有触发校验”通常可以收敛为三类明确原因：策略没有要求、客户端没有供证、服务端信任池与证书链不匹配。先看这三项，比反复更换 PEM 文件更快。

常见问题

只配置 ClientCAs，为什么客户端不带证书也能连上？

因为 ClientCAs 只是服务端验证客户端证书时使用的信任池，真正决定是否请求和强制校验的是 ClientAuth。零值默认是 NoClientCert。

VerifyClientCertIfGiven 和 RequireAndVerifyClientCert 怎么选？

前者允许没有客户端证书的连接，适合兼容迁移但不能表达强制 mTLS；后者要求客户端提供证书并通过服务端信任池验证，适合必须双向认证的入口。