Go x509.VerifyOptions校验证书链与服务名称的配置清单

用 Go 的 x509.Certificate.Verify 校验证书时，最容易混淆的是三个输入：Roots 决定“我信任谁”，Intermediates 负责“链条中间缺哪一段”，DNSName 负责“这张叶证书是否属于目标服务”。把三者混在一起，常见结果就是把中间证书误放进根池，或者链验证通过后仍然连错主机。

实用的配置顺序是：先准备信任锚，再补充中间证书，最后设置目标主机名和用途。若 Roots 为 nil，Go 可能使用系统根证书或平台验证器；若要验证内部 CA，则应显式创建根池。Verify 还不会替你完成吊销检查。

先把三类输入放回证书链位置

这里的“根”不是证书链里离叶证书最近的那张证书，而是你明确允许作为信任终点的证书。生产环境如果使用系统 CA，可以保留 Roots: nil；内部服务、测试 CA 或隔离环境则更适合显式传入自己的根池。

用 CertPool 组装可控的 VerifyOptions

根证书和中间证书都先放进独立的 CertPool。下面的代码假设 rootPEM、intermediatePEM 和已经解析出的 leaf 来自受信任的配置或服务响应；重点是池的职责，不是把某张证书永久写进代码。

package main

import (
    "crypto/x509"
    "fmt"
)

func verifyLeaf(leaf *x509.Certificate, rootPEM, intermediatePEM []byte) error {
    // Roots只放信任锚，内部CA场景不要用系统池替代它。
    roots := x509.NewCertPool()
    if ok := roots.AppendCertsFromPEM(rootPEM); !ok {
        return fmt.Errorf("读取根证书失败")
    }

    // 中间证书用于补链，但不因此获得信任锚身份。
    intermediates := x509.NewCertPool()
    if ok := intermediates.AppendCertsFromPEM(intermediatePEM); !ok {
        return fmt.Errorf("读取中间证书失败")
    }

    opts := x509.VerifyOptions{
        Roots:         roots,
        Intermediates: intermediates,
        DNSName:       "api.example.test", // 必须与叶证书SAN匹配
        KeyUsages:     []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
    }
    chains, err := leaf.Verify(opts)
    if err != nil {
        return fmt.Errorf("证书验证失败: %w", err)
    }
    if len(chains) == 0 {
        return fmt.Errorf("没有可用证书链")
    }
    return nil
}

若服务端只返回叶证书，调用方需要从部署配置或可信来源补齐中间证书；如果把中间证书放进 Roots，短期内可能“通过”，却会把本不该成为信任终点的证书提升为信任锚。

三个症状对应的排查顺序

UnknownAuthorityError：先确认根证书是否加入 Roots，再确认中间证书是否加入 Intermediates。空的自定义根池不会自动继承系统根。

HostnameError 或名称不匹配：检查 DNSName 是否写成实际访问的主机名，并查看叶证书的SAN。当前 Go 的主机名校验不应依赖遗留的 Common Name。

过期、用途不符或链条限制：检查每张证书的有效期、KeyUsages 和中间 CA 的约束。CurrentTime 只有在回放历史证书或固定测试时间时才需要显式设置，线上通常让它使用当前时间。

把配置写成上线前检查清单

1. 确认根池只包含团队明确承认的信任锚，并记录来源和轮换方式。
2. 确认中间池包含完整补链材料，但没有把叶证书或临时证书当作根。
3. 确认 DNSName 是连接目标，而不是证书文件名、服务别名或旧的Common Name。
4. 确认 KeyUsages 与用途一致；空列表按服务端认证语义处理，需要其他用途时显式填写。
5. 把“验证通过”理解为路径、名称、时间和用途检查通过，不把它当成吊销状态结论。

如果业务还需要吊销状态，应在验证成功后接入独立的吊销信息策略，并把失败结果与链验证错误区分记录。这样排查时才能知道是信任链缺材料、身份名称不对，还是额外安全策略未通过。

常见的两个边界问题

Roots 传 nil 和传空池有什么区别？nil 表示允许使用系统根或平台验证器；空的自定义池没有可信根，通常无法建立链。需要隔离信任域时，应显式传入正确的根池。

Verify 会检查证书是否被吊销吗？不会。它负责按证书链、名称、有效期、用途和相关约束构造并验证路径，吊销检查要由业务或另外的 PKI 组件补充。

事实依据：Go crypto/x509 官方文档 https://pkg.go.dev/crypto/x509；示例代码与排查表为本文原创整理。