x509 Verify 返回 unknown authority 但根证书已加载怎么办

根证书“已经加载”却仍出现 x509: certificate signed by unknown authority，通常不是 Verify 没看见文件，而是它没能用当前传入的证书池构建出“叶子证书 → 中间 CA → 受信任根 CA”的有效链。最先检查三件事：AppendCertsFromPEM 是否返回 true、加载后的那个 CertPool 是否真的传给了 VerifyOptions.Roots、中间证书是否放进 VerifyOptions.Intermediates。

Go crypto/x509 官方文档：https://pkg.go.dev/crypto/x509

我处理这类问题时，不再把“文件读取成功”当成证书加载成功，而是记录四个可比较指标：根 PEM 是否至少解析出一张证书、中间证书数量是否符合预期、相邻证书签名是否能核对、Verify 返回的链数量是否大于零。这样比反复替换证书文件快得多。

先把证书链拆成三个角色

Certificate.Verify 会尝试从当前叶子证书构建一条或多条链，链的末端必须来自 VerifyOptions.Roots；链中间缺少的签发者只能从 VerifyOptions.Intermediates 里找。根证书是信任锚，中间证书只是补链材料，两者放错池会改变验证含义。

如果证书由根 CA 直接签发，可以没有中间证书；但更常见的公网或企业 PKI 是三层链。只把根 CA 加入 Roots，并不能替代缺失的中间 CA。Go 官方文档对两个字段的定义很直接：Roots 是受信任根集合，Intermediates 是构建到根所需的非信任锚证书集合。

先记录加载基线，不要只看 ReadFile 是否成功

下面的辅助函数把“读取成功”和“至少解析到一张证书”拆开。后者才是 AppendCertsFromPEM 的语义。PEM 内容是私钥、空文件、错误编码，或者压根不是 CERTIFICATE 块时，读取文件仍可能成功，但追加会返回 false。

package trust

import (
    "crypto/x509"
    "fmt"
)

// appendPEM 把证书追加到指定池，并把解析失败变成显式错误。
func appendPEM(pool *x509.CertPool, name string, pemData []byte) error {
    if len(pemData) == 0 {
        return fmt.Errorf("%s: PEM 内容为空", name)
    }

    // 返回 false 表示没有任何证书被成功解析，不能继续假设已经加载。
    if ok := pool.AppendCertsFromPEM(pemData); !ok {
        return fmt.Errorf("%s: 未解析到 CERTIFICATE PEM 块", name)
    }
    return nil
}

这里最有价值的基线不是根池里“看起来有多少 Subject”。Subjects 已被官方标记为弃用，而且系统根池返回的 Subject 列表不保证包含系统根。更可靠的记录是：每个预期文件的追加布尔值、显式解析出的证书身份，以及最终返回链的长度。

把 Roots 与 Intermediates 明确传给同一次 Verify

我见过最隐蔽的一类错误是：初始化阶段创建了一个根池并成功追加证书，验证阶段却重新创建了另一个空池；或者把根池放进 tls.Config.RootCAs，手工调用 leaf.Verify 时又构造了没有 Roots 的 VerifyOptions。解决办法是让“加载”和“验证”共享同一个显式对象。

package trust

import (
    "crypto/x509"
    "fmt"
)

// verifyLeaf 使用明确的根池和中间池验证叶子证书。
func verifyLeaf(
    leaf *x509.Certificate,
    rootPEM []byte,
    intermediatePEM []byte,
    dnsName string,
) ([][]*x509.Certificate, error) {
    roots := x509.NewCertPool()
    if err := appendPEM(roots, "root", rootPEM); err != nil {
        return nil, err
    }

    intermediates := x509.NewCertPool()
    if len(intermediatePEM) > 0 {
        // 中间 CA 只参与补链，不应当因为方便而混入信任根池。
        if err := appendPEM(intermediates, "intermediate", intermediatePEM); err != nil {
            return nil, err
        }
    }

    chains, err := leaf.Verify(x509.VerifyOptions{
        Roots:         roots,
        Intermediates: intermediates,
        DNSName:       dnsName,
        // 空 KeyUsages 默认按服务端证书用途检查，此处保持默认语义。
    })
    if err != nil {
        return nil, fmt.Errorf("verify certificate chain: %w", err)
    }
    return chains, nil
}

这段代码的改动点只有两个：证书池由同一个函数创建并传入同一次验证；根和中间证书不再混用。修复后的通过标准也很清楚：err == nil 且 len(chains) > 0。如果仍失败，下一步不是继续“多加几个根”，而是核对链上证书是否真的互相匹配。

用四个证据判断到底断在哪里

根证书的 Common Name 与叶子证书的 Issuer 看起来相同，并不能证明它就是正确签发者。证书名称可以重复，真正决定签名关系的是公钥和签名。排查时我会同时看下面四组证据：

• 加载证据：根 PEM 和中间 PEM 的追加结果是否为 true。
• 身份关系：叶子证书的 RawIssuer 是否与候选签发者的 RawSubject 对应。
• 签名关系：CheckSignatureFrom 能否确认叶子由中间 CA 签发、中间 CA 由根 CA 签发。
• CA 约束：候选中间证书是否具有有效基本约束并且 IsCA 为真。

可以先把三个 PEM 各自解析成证书，再做离线关系核对。这样不会依赖 Common Name 猜测。

package trust

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

// parseCertificate 解析第一个证书 PEM 块，便于检查身份和签名关系。
func parseCertificate(name string, data []byte) (*x509.Certificate, error) {
    block, _ := pem.Decode(data)
    if block == nil || block.Type != "CERTIFICATE" {
        return nil, fmt.Errorf("%s: 找不到 CERTIFICATE PEM 块", name)
    }
    cert, err := x509.ParseCertificate(block.Bytes)
    if err != nil {
        return nil, fmt.Errorf("%s: 解析 DER: %w", name, err)
    }
    return cert, nil
}

// checkThreeLevelChain 核对叶子、中间和根证书之间的静态签发关系。
func checkThreeLevelChain(leaf, intermediate, root *x509.Certificate) error {
    if !bytes.Equal(leaf.RawIssuer, intermediate.RawSubject) {
        return fmt.Errorf("叶子 Issuer 与中间 CA Subject 不匹配")
    }
    if !intermediate.BasicConstraintsValid || !intermediate.IsCA {
        return fmt.Errorf("中间证书没有有效 CA 约束")
    }
    if err := leaf.CheckSignatureFrom(intermediate); err != nil {
        return fmt.Errorf("叶子签名不是由该中间 CA 产生: %w", err)
    }
    if err := intermediate.CheckSignatureFrom(root); err != nil {
        return fmt.Errorf("中间 CA 签名不是由该根 CA 产生: %w", err)
    }
    return nil
}

若叶子由根直接签发，就只检查叶子与根的关系，不要硬塞一个中间证书。若服务器返回了多个中间证书，则全部放进 Intermediates，让验证器选择可用链；不要把任意中间证书提升成受信任根来“消除报错”，那会扩大信任边界。

根据错误类型收窄假设

UnknownAuthorityError 表示找不到可接受的签发者。Go 的错误文本有时还会附带候选 CA 被拒绝的原因，例如候选证书无权签发。可以用 errors.As 区分它和主机名、有效期、用途等错误，避免把所有验证失败都当作根证书问题。

package trust

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

// classifyVerifyError 保留原错误，同时给排查分支一个稳定分类。
func classifyVerifyError(err error) string {
    var unknown x509.UnknownAuthorityError
    var hostname x509.HostnameError
    var invalid x509.CertificateInvalidError

    switch {
    case errors.As(err, &unknown):
        return fmt.Sprintf("unknown-authority: subject=%s", unknown.Cert.Subject)
    case errors.As(err, &hostname):
        return fmt.Sprintf("hostname-mismatch: host=%s", hostname.Host)
    case errors.As(err, &invalid):
        return fmt.Sprintf("certificate-invalid: reason=%v", invalid.Reason)
    default:
        return fmt.Sprintf("other: %v", err)
    }
}

这里的比较结果不是“错误消失了”这么模糊，而是从 root_loaded=false、intermediate_loaded=false 或签名关系失败，变成两项加载均成功、链关系核对通过、返回链数量至少为一。若错误改成主机名不匹配或用途不兼容，说明信任链已经能构建，接下来应处理 DNSName、SAN 或 KeyUsages，不应继续修改根池。

系统根池和自定义根池不要混淆

当 VerifyOptions.Roots 为 nil 时，Go 会使用系统根或平台验证器。显式传入一个由 x509.NewCertPool() 创建的池，就表示只信任这个池中的根，不会自动把系统根合并进来。如果既要信任系统根，又要增加企业 CA，应从 SystemCertPool 取得副本后再追加。

package trust

import (
    "crypto/x509"
    "fmt"
)

// rootsWithPrivateCA 在系统根副本中追加企业根 CA，不修改磁盘或其他池。
func rootsWithPrivateCA(privateRootPEM []byte) (*x509.CertPool, error) {
    roots, err := x509.SystemCertPool()
    if err != nil {
        return nil, fmt.Errorf("读取系统根池: %w", err)
    }
    if err := appendPEM(roots, "private-root", privateRootPEM); err != nil {
        return nil, err
    }
    return roots, nil
}

官方文档还提醒：对 SystemCertPool 返回值的修改只影响这个副本，不会写回磁盘，也不会影响下一次取得的其他池。因此“初始化时追加过”不代表后面重新调用 SystemCertPool 得到的对象也包含企业 CA。

修复前后该怎么比较

这四项足以覆盖大多数“根证书已经加载”的误判。对我来说，最有用的变化不是加入更多日志，而是把日志从“读取了某路径”改成“哪张证书被哪个池成功解析、哪一层签名成立、最终构建出几条链”。

几个容易走偏的边界

不要用跳过验证掩盖问题。 InsecureSkipVerify 会放弃正常的证书链和主机名验证，不是 unknown authority 的修复方式。

不要把用途错误当成信任错误。 VerifyOptions.KeyUsages 为空时默认检查服务端认证用途；验证客户端证书时应显式选择客户端认证用途。链能构建但用途不匹配时，错误通常会转向证书用途问题。

不要忽略 DNSName。 设置 DNSName 后还会验证叶子证书的 SAN。主机名不匹配说明信任链与名称是两个独立问题。

不要假设 Verify 会联网补齐中间证书。 手工调用 Certificate.Verify 时，应把需要的中间证书明确提供给 Intermediates。对端 TLS 配置也应发送完整中间链，但不应发送根证书。

不要把相同名称当成同一根。 证书的 Subject 或 Common Name 相同，公钥、序列号和签名仍可能完全不同。应核对实际证书和签名关系。

相关问题

根证书可以同时放进 Intermediates 吗？

技术上重复放入不一定立刻失败，但信任锚仍必须出现在 Roots 中。为了让边界清楚，根只放 Roots，中间 CA 只放 Intermediates。

只有一个自签名证书时怎么验证？

如果待验证证书本身就是明确受信任的自签名根，可以把该证书加入 Roots。但这等于直接信任它，必须确认这符合你的信任模型。

为什么换成 SystemCertPool 后有时能通过？

因为系统根池可能已经包含所需的公共根；也可能在特定平台走平台验证器。若目标是企业私有 CA，仍应明确追加私有根，并避免依赖不同机器上不一致的系统状态。

最终判断很简单：根文件存在不是证据，根 PEM 被解析也只是第一步。只有当前这次 Verify 拿到了正确的 Roots、完整的 Intermediates，并成功返回至少一条有效链，才算真正解决 unknown authority。