Go tls.ConnectionState VerifiedChains 为空时怎么判断证书验证

先说结论：tls.ConnectionState.VerifiedChains 为空，不等于 TLS 握手失败，也不等于对端没有证书。它表示 Go 的默认证书验证流程没有把对端证书构造成“已验证链”，常见原因是客户端启用了 InsecureSkipVerify，或者服务端使用了只请求证书、但不负责默认验证的 ClientAuth 模式。

排查时要把三个问题分开：握手是否完成、对端是否发送证书、默认校验器是否生成验证链。本文围绕这三个状态说明如何读取 tls.ConnectionState，以及什么时候应改用 PeerCertificates、x509.Certificate.VerifyHostname 或 VerifyConnection。

一、先区分握手状态、对端证书和验证链

ConnectionState() 只有在握手完成后才有完整意义。客户端或服务端拿到状态后，建议先检查 HandshakeComplete，再看 PeerCertificates 和 VerifiedChains，不要只根据某个切片是否为空判断证书是否安全。

package main

import (
    "crypto/tls"
    "fmt"
)

// summarizeState 只读取握手后的公开状态，不把 VerifiedChains 当成唯一成功标志。
func summarizeState(conn *tls.Conn, serverName string) error {
    state := conn.ConnectionState()
    if !state.HandshakeComplete {
        return fmt.Errorf("TLS 握手尚未完成") // 未完成时，状态字段不能用于结论
    }

    if len(state.PeerCertificates) == 0 {
        return fmt.Errorf("对端没有发送可读取的证书") // 服务端允许无客户端证书时可能出现
    }

    leaf := state.PeerCertificates[0]
    if len(state.VerifiedChains) == 0 {
        return fmt.Errorf("默认校验链为空，subject=%s", leaf.Subject.String()) // 仍需结合配置判断
    }

    if err := leaf.VerifyHostname(serverName); err != nil {
        return fmt.Errorf("证书主机名不匹配: %w", err) // 主机名校验是业务目标，不由切片长度替代
    }
    return nil
}

这里的三个字段含义不同：

二、客户端为什么会出现 VerifiedChains 为空

客户端配置中，最容易造成误判的是 InsecureSkipVerify: true。这个选项关闭默认的服务端证书与主机名校验，握手仍可能成功，PeerCertificates 也可能有内容，但 VerifiedChains 不会由默认校验器填充。

因此下面两种状态不能混为一谈：

• InsecureSkipVerify: false：客户端按默认规则校验证书，成功时通常可以读取 VerifiedChains。
• InsecureSkipVerify: true：默认校验被跳过，不能用 VerifiedChains 判断自定义校验是否成功。

如果业务必须使用自定义根证书、固定证书或特殊主机名规则，可以保留握手回调，但要在回调中明确完成证书验证。不要只设置 InsecureSkipVerify 后再把 PeerCertificates 的存在当作信任结论。

package main

import (
    "crypto/tls"
    "crypto/x509"
    "fmt"
)

// verifyWithPolicy 展示自定义校验入口；生产代码应使用明确的根证书与主机名策略。
func verifyWithPolicy(serverName string) *tls.Config {
    return &tls.Config{
        InsecureSkipVerify: true, // 关闭默认校验后，必须由 VerifyConnection 补回校验
        ServerName:         serverName,
        VerifyConnection: func(state tls.ConnectionState) error {
            if len(state.PeerCertificates) == 0 {
                return fmt.Errorf("服务端没有返回证书") // 先阻止空证书进入自定义逻辑
            }

            roots, err := x509.SystemCertPool()
            if err != nil {
                return fmt.Errorf("读取系统根证书失败: %w", err) // 不把根证书读取失败当作成功
            }

            intermediates := x509.NewCertPool()
            for _, cert := range state.PeerCertificates[1:] {
                intermediates.AddCert(cert) // 叶子证书单独作为待验证对象
            }

            _, err = state.PeerCertificates[0].Verify(x509.VerifyOptions{
                DNSName:       serverName,                         // 明确执行主机名校验
                Roots:         roots,                             // 指定信任根
                Intermediates: intermediates,                      // 提供服务端发送的中间证书
                KeyUsages:     []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
            })
            return err // 返回非 nil 会中止握手
        },
    }
}

这段配置中，VerifiedChains 仍可能为空，因为验证是在 VerifyConnection 里自行完成的。业务结论应来自回调返回值，而不是事后再检查 VerifiedChains。

三、服务端的 ClientAuth 决定验证链是否生成

服务端读取客户端证书时，要重点看 tls.Config.ClientAuth。它同时影响客户端是否需要发送证书，以及 Go 是否按服务端的 ClientCAs 进行默认验证。

所以服务端看到 PeerCertificates 有值但 VerifiedChains 为空，第一步不是改切片判断，而是回看 ClientAuth 是否采用了只收集证书、不验证证书的模式。

四、按业务目标选择正确的判断入口

如果只是记录对端证书信息，读取 PeerCertificates；如果要确认客户端连接到指定主机，使用叶子证书的 VerifyHostname；如果要加入自定义根证书、用途或策略，使用 VerifyConnection。这三种目标都不能简单替换成“len(VerifiedChains) > 0”。

// checkServerCertificate 根据业务目标拆开判断，避免一个布尔条件承担所有语义。
func checkServerCertificate(state tls.ConnectionState, host string) error {
    if !state.HandshakeComplete {
        return fmt.Errorf("握手未完成") // 先判断生命周期状态
    }
    if len(state.PeerCertificates) == 0 {
        return fmt.Errorf("没有对端证书") // 证书信息本身不存在
    }

    if err := state.PeerCertificates[0].VerifyHostname(host); err != nil {
        return fmt.Errorf("主机名验证失败: %w", err) // 只关心主机名时直接使用证书方法
    }

    if len(state.VerifiedChains) == 0 {
        return fmt.Errorf("未发现默认验证链，请检查 TLS 配置") // 作为观测信号，不伪装成完整安全结论
    }
    return nil
}

对于服务端的客户端证书策略，推荐把“证书是否提供”和“证书是否通过信任链验证”分别记录。例如日志中同时记录 peer_cert_count、verified_chain_count、client_auth_mode 和握手错误，定位问题时比只打印“证书为空”更准确。

常见问题

VerifiedChains 为空是不是证书无效？

不一定。它可能是默认校验被跳过、服务端只请求证书，或者证书由自定义回调验证。先看 TLS 配置和握手回调。

PeerCertificates 有值就代表连接可信了吗？

不是。它只表示对端发送了可解析的证书。信任关系还需要默认校验成功，或由应用自己的验证逻辑明确返回成功。

为什么 VerifyConnection 成功了，VerifiedChains 还是空？

因为 VerifyConnection 是应用层校验入口，回调返回 nil 只说明你的逻辑接受了连接，不会自动把结果写回 VerifiedChains。

小结

排查 tls.ConnectionState.VerifiedChains 时按“握手是否完成 → 对端是否发证书 → 默认校验是否构造验证链 → 是否使用自定义校验”的顺序看。客户端先检查 InsecureSkipVerify，服务端先检查 ClientAuth；需要主机名或自定义策略时，分别使用证书校验方法或 VerifyConnection。这样既不会把空链误报成握手失败，也不会把有证书误报成可信连接。