Go x509自签名证书加入Roots后仍失败的中间证书排查

把自签名 CA 加入 Roots 只解决了“信任从哪里开始”，不代表 Go 已经拿到了从服务器证书到这个根的完整路径。自签名根签发了中间 CA、再由中间 CA 签发服务证书时，服务端证书通常要和中间证书一起参与验证；客户端若只设置 Roots，仍可能得到 x509: certificate signed by unknown authority。

处理这类证书校验失败问题，不要直接把自签名证书丢进根证书池就完事，多数都是你漏导入了上层的中间证书，Go标准库的x509校验逻辑默认不会自动从系统根证书池反向补全证书链，得手动把涉及的中间证书也追加到你自定义的Roots池里才能正常通过校验。

先把 Roots、Intermediates 和 Leaf 分开

可以把证书链看成三层：最上面的自签名根证书是信任起点，中间 CA 证书负责签名传递，最下面的 Leaf 是实际服务证书。CertPool.AddCert 只是把证书加入一个池，并不会替你判断它应该属于哪一层；放错池会让排查变得更混乱。

用 VerifyOptions 补齐客户端验证输入

排查时先把 PEM 内容解析成证书对象，再分别构造两个证书池。下面的示例故意把根证书和中间证书拆成两个参数，便于发现“文件拿到了但没有放入验证选项”的问题。

package main

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

func parseCert(pemBytes []byte) (*x509.Certificate, error) {
    // 只接受第一个 CERTIFICATE 块，避免把私钥或其他 PEM 块误当成证书。
    block, _ := pem.Decode(pemBytes)
    if block == nil || block.Type != "CERTIFICATE" {
        return nil, errors.New("缺少 CERTIFICATE PEM 块")
    }
    cert, err := x509.ParseCertificate(block.Bytes)
    if err != nil {
        return nil, fmt.Errorf("解析证书失败: %w", err)
    }
    return cert, nil
}

func verifyLeaf(leafPEM, rootPEM, intermediatePEM []byte, dnsName string) error {
    // 根证书是信任锚点；不要把所有证书无差别塞进 Roots。
    root, err := parseCert(rootPEM)
    if err != nil {
        return err
    }
    roots := x509.NewCertPool()
    roots.AddCert(root)

    // 中间 CA 只用于拼接路径，不能替代 Roots 的信任声明。
    intermediate, err := parseCert(intermediatePEM)
    if err != nil {
        return err
    }
    intermediates := x509.NewCertPool()
    intermediates.AddCert(intermediate)

    leaf, err := parseCert(leafPEM)
    if err != nil {
        return err
    }
    // DNSName 同时检查 SAN；只验证链而不填它，会漏掉名称错误。
    _, err = leaf.Verify(x509.VerifyOptions{
        Roots:         roots,
        Intermediates: intermediates,
        DNSName:       dnsName,
        KeyUsages:     []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
    })
    return err
}

如果中间链有多级，就对每个中间证书调用 AddCert。它们不需要按文件名排序，但必须都是链上可能使用的非根证书。若服务端已经发送完整链，客户端通常不需要重复内置这些中间证书。

从错误类型判断到底是哪一层出错

不要看到验证失败就继续往 Roots 里追加证书。先保留原始错误，再按类型判断。UnknownAuthorityError 多半指向信任根或中间链缺失；HostnameError 则说明证书链可能已经成立，但证书的 SAN 与访问名不匹配。

var hostnameErr x509.HostnameError
var invalidErr x509.CertificateInvalidError
switch {
case errors.As(err, &hostnameErr):
    // 这里检查 DNSName、证书 SAN 和实际访问域名是否一致。
    fmt.Println("主机名不匹配:", hostnameErr)
case errors.As(err, &invalidErr):
    // 这里继续查看 Reason，区分过期、用途或约束失败。
    fmt.Println("证书属性无效:", invalidErr.Reason)
default:
    // 不要丢弃原错误，它通常包含缺失签发者等关键线索。
    fmt.Println("证书链或信任根异常:", err)
}

最后核对 TLS 服务端发送链

生产环境更推荐让 TLS 服务端发送“叶子证书 + 必需的中间证书”，根证书通常不应由服务端发送。这样不同语言和不同操作系统的客户端都能从本地信任库完成路径构造。若只有 Go 客户端失败，才进一步比较它使用的根池与系统根池是否不同。

修复后按四项复查：一是叶子证书的 SAN 包含实际域名；二是每个中间证书的签发者能连接到下一层；三是证书仍在有效期内且用途允许服务器认证；四是客户端没有把空的 Intermediates 或错误的 PEM 文件静默吞掉。内部自签名体系还要把根证书分发和轮换作为部署配置管理，不要把跳过验证当成修复。

常见问题

把中间证书也放进 Roots 能不能解决？

可能暂时绕过某些链路问题，但会扩大信任范围，掩盖服务端发送链缺失。更清晰的做法是中间证书放入 Intermediates，根证书放入 Roots。

Roots 已经加入，为什么仍是 unknown authority？

最常见原因是叶子证书由中间 CA 签发，而中间 CA 既未由服务端发送，也未放入 Intermediates；其次才是根证书并非实际签发链上的那一张。

Verify 成功后 TLS 仍失败怎么办？

检查 TLS 配置中的服务器名称、客户端认证用途、协议协商和服务端证书列表。单独调用 Verify 只能说明给定输入下的证书校验通过。