Go x509.VerifyOptions 怎样限制证书信任根

如果服务只应该信任公司内网 CA，却把 VerifyOptions.Roots 留为 nil，验证器就可能回到系统根证书集合，结果是“链能通过”但信任边界已经放大。Go 的最小配方是：自己创建一个 x509.CertPool，只加入允许的根证书，再把它传给 VerifyOptions.Roots；中间证书另放到 Intermediates，不要把它们混进信任锚。

官方资料：https://pkg.go.dev/crypto/x509#VerifyOptions

限制信任根的核心只有一处：Roots 使用“只含允许根证书”的自建池。Intermediates 负责补齐链路，DNSName 负责主机名匹配，三者不要互相替代。

问题：为什么只设置中间证书还不够

一次证书验证通常同时涉及叶子证书、一个或多个中间证书和根证书。Certificate.Verify 会根据 VerifyOptions 组装链：Roots 决定链最终允许落到哪些根，Intermediates 提供可选的非信任锚证书，DNSName 还会检查叶子证书是否匹配目标主机。

最小配方：只信任指定根证书

下面的示例假设你已经拿到了根 CA 的 PEM 内容。关键动作是调用 x509.NewCertPool，并检查 AppendCertsFromPEM 的返回值；如果根证书没有成功加入，继续验证会把输入错误隐藏在后面的 unknown authority 中。

package main

import (
    "crypto/x509"
    "fmt"
)

func verifyWithPrivateRoot(leaf *x509.Certificate, rootPEM []byte, intermediates []*x509.Certificate, host string) error {
    // 自建池只加入业务允许的根 CA，避免回退到系统根集合。
    roots := x509.NewCertPool()
    if ok := roots.AppendCertsFromPEM(rootPEM); !ok {
        return fmt.Errorf("加入受信任根 CA 失败")
    }

    // 中间证书用于补链，但不改变信任锚的范围。
    intermediatePool := x509.NewCertPool()
    for _, cert := range intermediates {
        if cert == nil {
            return fmt.Errorf("中间证书列表包含 nil")
        }
        intermediatePool.AddCert(cert)
    }

    // Roots 限定信任边界，DNSName 和 KeyUsages 继续收紧验证条件。
    opts := x509.VerifyOptions{
        Roots:         roots,
        Intermediates: intermediatePool,
        DNSName:       host,
        KeyUsages:     []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
    }
    _, err := leaf.Verify(opts)
    return err
}

这段配方的判断点是：Roots 非空且只包含指定根，Intermediates 仅保存链路中的中间证书，leaf.Verify(opts) 同时执行链验证和主机名、用途约束。实际项目可把根池在进程启动时构建一次，再复用到多次验证中。

变体：从多份 PEM 中选择允许的根

如果配置文件里包含多个候选证书，仍然不要直接把整份系统证书复制进 Roots。可以根据配置明确选择允许的根，再把选中的 PEM 追加到新池。下面的代码只展示配置决策，字段含义写在代码块外，避免破坏 JSON 格式。

// allowedRootPEM 应来自受控配置，而不是临时下载的未知证书。
roots := x509.NewCertPool()
if !roots.AppendCertsFromPEM(allowedRootPEM) {
    return fmt.Errorf("配置的根 CA 无法解析")
}

opts := x509.VerifyOptions{
    // Roots 非 nil 时，验证只在这个池中寻找信任锚。
    Roots: roots,
    // 叶子证书的主机名仍然必须单独校验。
    DNSName: "api.internal.example",
}
chains, err := leaf.Verify(opts)
if err != nil {
    return fmt.Errorf("证书链不受信任: %w", err)
}
if len(chains) == 0 {
    return fmt.Errorf("没有构建出可用证书链")
}

这里的 Roots 和 DNSName 是两个独立约束：根池决定“谁能签发出可信链”，主机名决定“这张叶子证书是否服务于目标主机”。两者都满足，才是适合业务连接的结果。

兼容坑：Roots nil、空池与中间证书不要混淆

• Roots: nil：表示使用系统根或平台验证器，适合公共 TLS 场景，但不适合“只信任公司 CA”的隔离需求。
• 空的 CertPool：它不是“使用系统根”的别名，而是一个没有可用信任锚的受限集合，通常会导致链无法建立。
• 把中间证书加入 Roots：这会改变信任模型，让该中间证书直接成为可接受的锚点；如果目标只是补链，应放进 Intermediates。
• 只看返回的 chains：真正的成功信号是 err == nil；返回链条便于记录选择结果，但不能代替错误判断。

常见问题

自建 Roots 后还要不要设置 DNSName？

要。Roots 只限制信任锚，不能证明叶子证书的 SAN 与目标域名匹配。面向服务连接时，通常应同时设置 DNSName。

根证书和中间证书都在服务端返回，还要填 Intermediates 吗？

不一定。Intermediates 主要用于提供本地已有但验证输入中缺少的中间证书；是否需要填取决于你传给 Verify 的证书链材料。

限制信任根能否替代证书吊销检查？

不能。它解决的是“允许哪些根作为信任锚”，不是完整的吊销状态或业务授权判断。吊销、权限和轮换策略仍需单独设计。

回到标题问题，最小答案就是：创建只包含允许根 CA 的 CertPool，赋给 VerifyOptions.Roots；中间证书放到 Intermediates，再按需要设置 DNSName 和 KeyUsages。这样限制的是信任边界，而不是把证书链验证的其他条件一并省略。