Go crypto/x509验证证书链与根池的排查方法

Go 程序遇到 x509: certificate signed by unknown authority 时，先不要把校验全部关掉。多数问题来自证书角色放错位置：服务端叶子证书应作为待验证对象，中间证书放进 Intermediates，真正被信任的根证书才放进 Roots。如果只是把中间证书加入根池，链可能暂时通过，却改变了信任边界。

先把证书链的三个角色分开

一条常见链路是“叶子证书—中间 CA—根 CA”。叶子证书包含服务域名，是本次 cert.Verify 的接收者；中间 CA 通常随服务端链或配置文件提供，但它不是信任锚；根 CA 代表客户端愿意信任的起点。VerifyOptions 的字段设计正是把这三种输入拆开。

排查时先记录每张证书的 Subject、Issuer、DNSNames、有效期和 IsCA。不要只看文件名，ca.pem 可能是中间 CA，chain.pem 也可能混入根证书。

用正确的根池和中间池构造 VerifyOptions

公共 CA 场景优先从系统根池开始，再把业务私有 CA 追加进去；完全私有 PKI 才使用空池并明确加入私有根。下面的示例只展示验证边界，文件内容由部署系统提供。

package main

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

func verifyServerCert(leafPEM, intermediatePEM []byte, host string) error {
    // 叶子证书是待验证对象，不把它放入根池。
    leafBlock, _ := pem.Decode(leafPEM)
    if leafBlock == nil {
        return fmt.Errorf("解析叶子证书失败")
    }
    leaf, err := x509.ParseCertificate(leafBlock.Bytes)
    if err != nil {
        return fmt.Errorf("解析叶子证书失败: %w", err)
    }

    // 系统根池是信任锚；追加私有根时应使用它的副本。
    roots, err := x509.SystemCertPool()
    if err != nil {
        return fmt.Errorf("读取系统根池失败: %w", err)
    }
    privateRootPEM, err := os.ReadFile("private-root.pem")
    if err != nil {
        return fmt.Errorf("读取私有根失败: %w", err)
    }
    if ok := roots.AppendCertsFromPEM(privateRootPEM); !ok {
        return fmt.Errorf("私有根 PEM 中没有可解析证书")
    }

    // 中间证书只帮助建链；它们不是本次信任起点。
    intermediates := x509.NewCertPool()
    if ok := intermediates.AppendCertsFromPEM(intermediatePEM); !ok {
        return fmt.Errorf("中间证书 PEM 中没有可解析证书")
    }
    opts := x509.VerifyOptions{
        DNSName:       host, // 按 SAN 校验目标主机名。
        Roots:         roots,
        Intermediates: intermediates,
        KeyUsages:     []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
    }
    if _, err := leaf.Verify(opts); err != nil {
        var hostnameErr x509.HostnameError
        var unknownErr x509.UnknownAuthorityError
        if errors.As(err, &hostnameErr) {
            return fmt.Errorf("主机名不匹配: %w", err)
        }
        if errors.As(err, &unknownErr) {
            return fmt.Errorf("根池或中间链不完整: %w", err)
        }
        return fmt.Errorf("证书链验证失败: %w", err)
    }
    return nil
}

这里有两个容易混淆的选择：SystemCertPool 返回系统根池的副本，追加内容不会写回操作系统；NewCertPool 则是空池，若只用它就只信任手动加入的根。服务端证书的中间链缺失时，应该补 Intermediates，而不是把中间证书伪装成根。

把错误映射到具体排查动作

特别要注意，VerifyHostname 只回答“证书是否适用于这个名字”，不能替代完整链验证。完整请求通常需要同时满足：链能到达信任根、所有证书在有效期内、用途匹配，以及叶子证书的 SAN 与目标主机一致。

现场排查清单与边界

可以按“输入—池—环境—错误”四列留痕：输入列确认叶子和中间证书都能被 PEM 解码；池列记录根池来自系统、私有文件还是测试构造；环境列对比容器与宿主机的证书目录、SSL_CERT_FILE 和 SSL_CERT_DIR；错误列保留原始错误类型，而不是只记录一行字符串。这样能区分“生产镜像缺 CA”和“链本身缺中间证书”。

如果在 macOS 或 Windows 上依赖平台验证器，Roots=nil 的细节可能与显式传入 CertPool 不同；需要可重复的测试结果时，建议显式构造根池并固定 CurrentTime。本文只讨论 x509 的链、根池、域名和用途验证，不涉及 HTTP 客户端重试、代理证书注入或 TLS 版本协商。

相关问题

为什么把中间证书加入 Roots 也可能通过

因为 Roots 是信任起点，验证器可以把被加入的证书直接视为锚点。这样绕过了原本应由上级根约束的信任关系，部署上不够清晰；更合适的做法是把中间证书放入 Intermediates。

SystemCertPool 失败时能否直接使用 NewCertPool

可以，但必须明确加入应用实际信任的根证书；空池不会自动继承操作系统 CA。对公共站点连接，直接换空池通常会制造更多 UnknownAuthorityError。

只调用 VerifyHostname 是否安全

不够。它只做主机名匹配，不能证明证书链最终连接到受信任根，也不替代有效期、用途和链路检查。