Go crypto/x509 CertPool 怎么判断证书链：Roots、Intermediates 与验证结果边界

用 Go 检查一张 TLS 证书时，最容易混淆的是“证书能不能拼成链”和“这条链是不是信任的”。crypto/x509 把这两件事放在同一套 API 里，但输入池的职责并不相同：VerifyOptions.Roots 提供信任锚，VerifyOptions.Intermediates 只补齐中间证书，主机名还需要单独调用 VerifyHostname。

排查证书验证失败时，先确认叶证书、Roots 和 Intermediates 的角色，再看主机名；把中间证书误放进 Roots，或者只验证链不验证域名，都会得到错误结论。

先把三种证书角色分开

一张常见的服务端证书链可以抽象成叶证书、一个或多个中间 CA，再到根 CA。代码里的变量名最好直接体现这个角色，否则排错时很容易把“签发者”当成“信任锚”。

• leaf：要检查的服务端证书，调用它的 Verify。
• intermediates：不直接作为信任终点，只在构链时提供中间节点。
• roots：最终被信任的根证书池，验证链必须落到这里。

x509.NewCertPool 创建空池，AddCert 把已经解析出的证书加入池。生产代码从 PEM 加载时，还要检查 AppendCertsFromPEM 的布尔返回值，避免文件内容根本没有被解析却继续验证。

Verify 负责把链走到 Roots

最小的验证代码只需要把叶证书、根池和中间池放进 VerifyOptions。这里的 Intermediates 不是信任列表；它只是给构链算法提供候选中间证书。

roots := x509.NewCertPool()
roots.AddCert(root)

intermediates := x509.NewCertPool()
intermediates.AddCert(intermediate)

chains, err := leaf.Verify(x509.VerifyOptions{
    Roots:         roots,
    Intermediates: intermediates,
    KeyUsages:     []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
})
if err != nil {
    return fmt.Errorf("verify certificate chain: %w", err)
}
if len(chains) == 0 {
    return errors.New("no verified chain")
}

成功返回的每条链都从 leaf 开始，最后落在 roots 中的证书。若中间证书缺失，常见结果是验证失败；把它临时塞进 Roots 可能让测试“通过”，却改变了信任边界，不能作为修复。

验证链之后再核对主机名

证书链可信，只说明签发关系、有效期、用途等验证条件满足。客户端真正连接的是一个主机名，还要在同一个叶证书上调用 VerifyHostname。

if err := leaf.VerifyHostname("api.example.com"); err != nil {
    return fmt.Errorf("verify hostname: %w", err)
}

chains, err := leaf.Verify(opts)
if err != nil {
    return err
}
_ = chains

主机名检查失败时，不要通过关闭校验或改用证书的普通主题字段来绕过。证书的 SAN、通配符覆盖范围和实际请求主机名必须按同一规则核对。

三个失败现象对应三条排查路径

报 unknown authority

先看 Roots 是否真的包含信任锚，再确认 Intermediates 是否提供了服务器没有随握手发送的中间证书。若使用系统根池，注意容器里的系统证书包可能不完整。

链能验证，主机名却失败

这通常不是 Roots 的问题，而是请求的主机名不在叶证书的 SAN 覆盖范围内。记录实际连接主机名和证书中的 DNS 名称，别只看证书链长度。

测试环境通过，线上失败

固定测试用的 CurrentTime 只能帮助重现时间边界，不能替代线上信任根。排查时把根池来源、中间证书集合、目标主机名和 KeyUsages 一起记录，避免只复制一段错误字符串。

不要把证书池当成万能开关

CertPool 解决的是证书集合和构链输入，VerifyOptions 决定用途、时间和信任边界，VerifyHostname 决定目标名称是否匹配。三者职责分开后，错误信息才有明确的下一步：链失败看 Roots/Intermediates，名称失败看 SAN 与目标主机名。

相关问题

可以把所有中间证书放进 Roots 吗？

不建议。这样会把中间 CA 也提升为信任终点，扩大信任范围；正确做法是放进 Intermediates，让链继续走到受信任的根。

Roots 传 nil 会怎样？

验证器可能使用系统根或平台验证器，具体行为取决于平台和系统根是否可用。需要可重复的私有 CA 验证时，应显式构造根池。

Verify 成功后还需要 VerifyHostname 吗？

服务端证书用于某个具体主机名时需要。链可信与名称匹配是两个条件，不能用其中一个替代另一个。

把证书验证拆成可解释的两步

实际代码里，先用明确的 Roots 和 Intermediates 完成链验证，再对连接目标调用 VerifyHostname。这条顺序既符合 API 的职责划分，也能让“信任问题”和“名称问题”在日志与测试中分别收敛。