Go crypto/x509 怎样校验证书链

我在接入一套使用内网 CA 的 HTTPS 服务时，最容易遇到的不是 PEM 解析失败，而是把“信任根”和“用来拼链的中间证书”放进了同一个概念里。Go 的 crypto/x509 已经提供了完整的链构建器，关键是把证书放进正确的池，再把用途约束写进 VerifyOptions。

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

本文只处理自定义根证书池、补齐中间证书、DNS 名称和扩展用途校验，不展开 OCSP、CRL 或 TLS 握手过程。

先分清 Roots 与 Intermediates

Roots 表示你愿意信任的根证书集合，是链条的信任锚；Intermediates 表示帮助 Go 从叶证书找到根证书的中间证书集合，它们本身不是信任锚。Certificate.Verify 会尝试把叶证书连接到 Roots 中的某个根，并返回一条或多条候选链。

因此，只有一张服务端证书时，先确认它是叶证书还是根证书；如果服务端没有把中间证书带齐，就需要把中间证书放进单独的池。把中间证书误当成根证书，会让“信任谁”和“如何拼链”混在一起，后续替换 CA 时很难排查。

解析 PEM 并组装证书池

下面的函数把一段 PEM 解析成 *x509.Certificate。根证书进入 NewCertPool 返回的池，中间证书进入另一个池；两者都检查输入是否真的包含证书。

package certverify

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

func parseCertificate(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 {
        // 解析失败时保留底层错误，便于定位 DER 或 PEM 输入问题。
        return nil, fmt.Errorf("解析证书失败: %w", err)
    }
    return cert, nil
}

func buildPools(rootPEM, intermediatePEM []byte) (*x509.CertPool, *x509.CertPool, error) {
    root, err := parseCertificate(rootPEM)
    if err != nil {
        return nil, nil, err
    }

    roots := x509.NewCertPool()
    // Roots 只放信任锚，不把叶证书或中间证书混入这里。
    roots.AddCert(root)

    intermediates := x509.NewCertPool()
    if intermediatePEM != nil {
        intermediate, err := parseCertificate(intermediatePEM)
        if err != nil {
            return nil, nil, err
        }
        // 中间证书用于拼链，但不单独扩大信任范围。
        intermediates.AddCert(intermediate)
    }
    return roots, intermediates, nil
}

生产代码中如果证书文件包含多个 PEM 块，应循环调用 pem.Decode，并把每个 CERTIFICATE 块加入对应池；示例为了突出职责分工，只保留单个根证书和单个中间证书。也可以使用 AppendCertsFromPEM 批量加入证书，但仍要先确定这批数据属于 Roots 还是 Intermediates。

配置 VerifyOptions 并调用 Verify

证书池准备好后，把叶证书交给 Verify。如果目标是服务端证书，明确写入 ExtKeyUsageServerAuth；如果是客户端证书，则改成 ExtKeyUsageClientAuth。DNSName 会把主机名匹配也纳入校验。

package certverify

import (
    "crypto/x509"
    "fmt"
)

func verifyServerCertificate(leaf *x509.Certificate, roots, intermediates *x509.CertPool, host string) error {
    opts := x509.VerifyOptions{
        DNSName:       host,
        Roots:         roots,
        Intermediates: intermediates,
        // 显式声明用途，避免把“能成链”误认为“能用于服务端认证”。
        KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
    }

    chains, err := leaf.Verify(opts)
    if err != nil {
        // Verify 的错误通常能帮助区分信任根、用途或有效期配置问题。
        return fmt.Errorf("证书链校验失败: %w", err)
    }
    if len(chains) == 0 {
        return fmt.Errorf("证书链校验没有返回链")
    }
    // chains[0] 的第一个元素是叶证书，最后一个元素来自 Roots。
    return nil
}

如果不设置 DNSName，这段代码仍可能通过链和用途检查，但不会替你确认叶证书是否覆盖目标主机名。CurrentTime 为零时使用当前时间；需要离线回放历史证书时，才显式传入固定时间。

错误信息怎样对应到配置问题

我通常按下面三层看错误，而不是先把所有证书重新导入一遍：

• 未知签发者：优先检查根证书是否真的放入 Roots，以及中间证书是否放入 Intermediates。
• 用途不匹配：检查叶证书和链上证书的扩展用途，并确认 KeyUsages 没有把服务端证书当成客户端证书使用。
• 名称或时间失败：检查 DNSName 是否与 SAN 匹配，以及当前时间是否落在证书有效期内。

还要记住，Verify 不是完整的吊销状态服务：官方文档明确说明它不会执行证书吊销检查。若业务要求实时吊销判断，需要在链校验之外接入独立的 CRL 或 OCSP 策略，并把失败结果纳入连接决策。

一张表记住配置边界

相关问题

Roots 传 nil 会发生什么？

会使用系统根证书或平台验证器；容器、定制运行环境和内网 CA 场景通常更适合显式传入自己的 Roots。

为什么证书签名正确仍然校验失败？

签名正确只说明局部关系成立，完整校验还要考虑信任锚、链路、DNS 名称、有效期和扩展用途。