Go tls.ConnectionState.PeerCertificates 怎样判断服务器证书链是否完整

排查 Go TLS 客户端“证书链不完整”时，最容易混淆的是 PeerCertificates 和 VerifiedChains。前者表示对端在握手中发送、并被 Go 解析出来的证书列表；后者表示本地验证器从这些证书出发，连接到信任根后形成的验证链。它们不是同一个结果。

先把“发送完整”和“验证完整”分成两件事

服务器通常发送叶子证书和一个或多个中间证书，客户端再使用自己的信任根完成链构建。PeerCertificates 记录的是对端实际发送的解析结果，顺序通常从叶子证书开始；服务器没有发送中间证书时，这个切片仍可能包含叶子证书，所以长度为 1 只是一个排查信号，不是最终结论。

VerifiedChains 的第一项对应 PeerCertificates[0]，末端来自客户端的 RootCAs 或服务端的 ClientCAs。因此，判断“这条链是否被当前配置认可”，应优先看它，而不是只数对端发了几张证书。

读取状态前先确认握手已经结束

ConnectionState() 返回的状态只有在握手完成后才有意义。握手会由第一次 Read 或 Write 自动触发，也可以显式调用 Handshake。如果排障日志在握手之前就读取状态，看到的空字段不能用来证明证书链缺失。

package main

import (
    "crypto/tls"
    "fmt"
)

// describeState 只读取已经完成握手的连接状态，避免把未初始化字段当成证据。
func describeState(state tls.ConnectionState) {
    if !state.HandshakeComplete {
        fmt.Println("TLS 握手尚未完成，暂不判断证书链")
        return
    }

    // PeerCertificates 表示对端发送的证书，通常第一个是叶子证书。
    fmt.Printf("对端证书数: %d\\n", len(state.PeerCertificates))

    // VerifiedChains 非空才说明本地构造出了至少一条通过信任配置的链。
    if len(state.VerifiedChains) == 0 {
        fmt.Println("尚未得到本地验证链：检查是否跳过校验或信任配置")
        return
    }

    // 每条验证链都从对端叶子证书连接到本地信任根。
    for index, chain := range state.VerifiedChains {
        fmt.Printf("验证链 %d 长度: %d\\n", index+1, len(chain))
    }
}

这段函数只负责解释状态，不创建连接，也不把示例输出冒充成某次真实握手结果。接入实际客户端时，应在 Handshake 成功后或读写触发握手成功后调用它。

用 PeerCertificates 判断服务器到底发送了什么

在客户端侧，PeerCertificates 不应为空；第一项是服务器证书，后续项通常是服务器附带的中间证书。排查时可以记录证书主题、颁发者和数量，但不要修改这个切片或其中的证书对象。

如果数量只有 1，可能是服务器只发了叶子证书，也可能是该服务器证书本身能由客户端已有的中间证书完成构建。相反，数量大于 1 也不等于链一定正确：中间证书可能顺序不合适、用途不匹配或最终无法连接到受信任根。

用 VerifiedChains 判断“能不能被当前配置信任”

客户端没有设置 InsecureSkipVerify 时，VerifiedChains 是判断链验证结果的关键。它非空，表示 Go 按当前信任根和主机名等校验条件构造出了一条或多条验证链；它为空时，应继续区分两类情况：

• 握手失败前读取状态，字段还没有形成有效结果。
• 连接允许跳过常规证书校验，或当前角色和认证配置本来就不会生成验证链。

所以排障日志最好同时记录 HandshakeComplete、InsecureSkipVerify 的配置意图、len(PeerCertificates) 和 len(VerifiedChains)。日志中不要打印私钥、完整敏感扩展或不必要的证书原文。

服务端场景不能照搬客户端结论

在服务端，PeerCertificates 表示客户端发送的证书。若 ClientAuth 没有要求客户端提供证书，服务端看到空列表是正常状态；只有在要求或验证客户端证书的配置下，才应把空列表作为认证链排查线索。对应的 VerifiedChains 是否形成，也取决于服务端的客户端认证模式和 ClientCAs 配置。

这也是“证书链是否完整”必须带角色和配置条件的原因：客户端关注服务器链能否通过本地 RootCAs，服务端关注客户端证书是否按 ClientAuth 与 ClientCAs 规则被接受。

一张速查表避免误判

排障时按这个顺序收集证据

1. 确认握手是否完成，以及错误发生在握手前还是握手后。
2. 在客户端记录 PeerCertificates 数量和顺序，判断服务器实际发送了什么。
3. 记录 VerifiedChains 数量，确认是否形成了连接到信任根的链。
4. 把 RootCAs、InsecureSkipVerify、主机名和服务端认证角色放入同一份排障上下文。
5. 如果发送列表和验证链不一致，优先检查信任根、中间证书、主机名和认证模式，而不是直接增加或删除证书。

常见追问

PeerCertificates 长度为 1 就是服务器漏发中间证书吗？

不一定。它只说明对端发送列表里有一张解析后的证书；最终还要看本地是否能用已有信任材料构造出 VerifiedChains。

VerifiedChains 为空能说明证书校验失败吗？

不能单独说明。先确认握手已经完成，再检查是否启用了跳过校验、当前是客户端还是服务端，以及对应的信任配置。

应该打印完整证书内容来排查吗？

通常不需要。记录数量、主题、颁发者、有效期和验证结果就足够定位大多数链路问题；完整原文应避免进入普通业务日志。

判断 Go TLS 证书链时，最稳妥的做法是把“对端发送了什么”和“本地信任了什么”分开记录：PeerCertificates 给出发送列表，VerifiedChains 给出验证结果，HandshakeComplete 则决定这些字段是否已经具备解释价值。