Go crypto/x509 CertPool AddCert 怎么验证证书链：根证书池与握手失败定位

内网服务换了自签名 CA 后，Go 客户端最常见的报错是 x509: certificate signed by unknown authority。先别急着关闭证书校验：如果服务端链条本身完整，问题通常只是客户端用于 Verify 的根证书池里没有这张 CA。把证书解析成 *x509.Certificate，通过 AddCert 放入正确的 CertPool，再让 Verify 使用它，定位会清楚很多。

先决定信任边界：保留系统根证书时从 SystemCertPool 克隆；只信任内网 CA 时用 NewCertPool，再显式 AddCert，不要把 InsecureSkipVerify 当成修复。

先把握手失败拆成一条可验证的链路

排查场景假设为：服务端给出叶子证书，签发它的内网 CA 文件保存在 certs/internal-ca.pem，客户端需要访问 api.intra.example。这不是让程序“信任所有证书”，而是让验证器知道一条明确的信任根。

这几个实体的职责不要混在一起：

第一张图把 SystemCertPool、NewCertPool、AddCert 和 Verify 放在同一条调用链上。图片中的节点都对应下面的真实代码，不代表额外 API。

用 AddCert 给 Verify 准备正确的根证书

下面的示例读取 PEM 编码的内网 CA，并验证一张已经拿到的叶子证书。真实客户端通常从 TLS 握手得到叶子证书；为便于复用，示例把校验逻辑单独放进 verifyServerCert。

package certcheck

import (
    "crypto/x509"
    "encoding/pem"
    "fmt"
    "os"
)

func verifyServerCert(leaf *x509.Certificate, caPEM []byte, host string) error {
    block, _ := pem.Decode(caPEM)
    if block == nil || block.Type != "CERTIFICATE" {
        return fmt.Errorf("internal CA PEM is invalid")
    }
    ca, err := x509.ParseCertificate(block.Bytes)
    if err != nil {
        return fmt.Errorf("parse internal CA: %w", err)
    }

    roots := x509.NewCertPool()
    roots.AddCert(ca)
    opts := x509.VerifyOptions{
        DNSName: host,
        Roots:   roots,
    }
    _, err = leaf.Verify(opts)
    return err
}

func loadCA(path string) ([]byte, error) {
    return os.ReadFile(path)
}

这里的关键顺序是 ParseCertificate → NewCertPool → AddCert → Verify。如果还要信任公共 CA，可以把空池换成 SystemCertPool，然后在返回的副本上继续 AddCert；如果业务只允许内网 CA，空池反而更容易审计。

第二张图只展示这条真实的数据路径：caPEM 进入 ParseCertificate，结果进入 AddCert，最后由 Verify 根据 DNSName 产出成功或错误状态。

SystemCertPool 与 NewCertPool 怎么选

选择只看一个问题：客户端是否仍然需要系统公开 CA。

• 既访问公网又访问内网：调用 SystemCertPool，检查错误后在副本上 AddCert。不同平台的系统池来源可能不同，不能假设每台机器都一样。
• 只访问固定内网服务：调用 NewCertPool，只加入部署时下发的 CA。这会缩小信任范围，但也意味着轮换 CA 时必须同步配置。
• 使用 AppendCertsFromPEM 批量加载 PEM 时，必须检查返回的 bool；返回 false 说明没有成功解析出证书。

不要把 Roots 和 Intermediates 颠倒。签发服务器证书的根 CA 放进 Roots；服务端链里缺失、但客户端拿得到的中间证书，才放入 Intermediates。把叶子证书塞进根池只能掩盖配置问题。

验证结果不对时，按证据逐项收口

如果错误仍是 unknown authority，先打印 CA 的 Subject 和叶子证书的 Issuer，确认两者确实属于同一条链。若变成主机名错误，说明根信任已经通过，应继续检查 DNSName 与证书 SAN。若是过期错误，则看证书有效期和机器时钟。证书池只解决信任根问题，不会绕过这些检查。

生产接入建议把验证失败记录成可检索字段：服务名、证书 Subject、Issuer、验证错误类型。不要把完整 PEM 或私钥写进日志。证书轮换时，先把新 CA 加入池并完成灰度，再移除旧 CA。

相关问题

SystemCertPool 返回的池可以直接 AddCert 吗？

可以。官方文档说明它返回系统池的副本，修改副本不会写回系统；这正适合给单个客户端叠加内网 CA。

AddCert 加入的是中间证书还是根证书？

AddCert 只是把证书加入池，语义取决于你把这个池传给哪个选项。作为 VerifyOptions.Roots 时，应放信任根；中间证书应放 Intermediates。

为什么证书池正确仍然会验证失败？

常见原因是 DNSName 不匹配、证书过期、服务端未发送必要中间证书，或叶子证书与内网 CA 并非同一条链。

收尾检查

把问题收敛成四个检查点：CA 是否成功解析、是否真的执行了 AddCert、VerifyOptions.Roots 是否指向这一个池、DNSName 是否与证书 SAN 一致。这样修复的是信任边界，而不是把 TLS 安全检查整体关掉。