证书链通过验证却不满足策略 OID 是什么原因

证书链能从叶子证书一路建到受信任根证书，只能说明签名、有效期、名称和用途等基础条件通过；它不等于链上存在你要求的策略 OID。Go 1.24 起，crypto/x509 的 Certificate.Verify 才会根据 VerifyOptions.CertificatePolicies 做策略验证，策略图不满足时仍会返回错误。

官方地址：https://pkg.go.dev/crypto/x509

先把“链通过”和“策略通过”分成两次判断

建议先用一份不带策略的 VerifyOptions 建立基线，再加入目标 OID。下面的示例只展示验证边界，证书加载部分沿用业务已有的 PEM 解析代码。

package main

import (
    "crypto/x509"
    "fmt"
)

func verifyWithPolicy(cert *x509.Certificate, roots, intermediates *x509.CertPool) error {
    // 先固定根池和中间证书池，避免系统根变化干扰排查。
    base := x509.VerifyOptions{
        Roots:         roots,
        Intermediates: intermediates,
        KeyUsages:     []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
    }
    if _, err := cert.Verify(base); err != nil {
        return fmt.Errorf("基础链验证失败: %w", err)
    }

    // CertificatePolicies 只声明可接受的 OID，不会替证书补写策略扩展。
    base.CertificatePolicies = []x509.OID{x509.OIDFromInts([]uint64{1, 2, 3, 4})}
    if _, err := cert.Verify(base); err != nil {
        return fmt.Errorf("策略验证失败: %w", err)
    }
    return nil
}

如果第一处失败，问题还在根证书、签名、有效期、名称或 EKU；如果第一处成功、第二处失败，才进入策略 OID 和策略图排查。注意示例使用的是 Go 1.24 新增的 x509.OID 接口，不能把它误写成旧版本的 asn1.ObjectIdentifier 字段。

检查链上证书是否真的携带目标策略

CertificatePolicies 的值来自证书扩展，而不是来自调用方的配置。Go 1.24 仍会填充兼容用的 PolicyIdentifiers，但新代码应优先读取 Policies，因为它能表达更完整的 OID。一个常见误区是只打印叶子证书：中间 CA 的策略约束同样会影响最终策略图。

package main

import (
    "crypto/x509"
    "fmt"
)

func printPolicies(chain []*x509.Certificate) {
    for index, cert := range chain {
        // 同时打印主题和策略，先定位 OID 在哪一层消失。
        fmt.Printf("链[%d] %s\\n", index, cert.Subject.CommonName)
        for _, policy := range cert.Policies {
            fmt.Printf("  Policies: %s\\n", policy.String())
        }
        // 旧代码可能仍读取这个兼容字段，结果会漏掉大整数分量的 OID。
        for _, policy := range cert.PolicyIdentifiers {
            fmt.Printf("  PolicyIdentifiers: %s\\n", policy.String())
        }
    }
}

排查时可以做一张简单对照表：

策略 OID 缺失时，按这四个边界定位

第一，确认 OID 是完整的点分十进制值，不能把企业自定义 OID 截断或把字符串比较当成策略匹配。第二，检查中间证书是否被放进 Intermediates；少一张证书可能导致链能换另一条路径，却无法得到期望策略图。第三，关注 anyPolicy、显式策略和策略映射等限制，不能简单理解成“链上任意一层出现目标 OID 就算通过”。第四，确认程序确实运行在 Go 1.24 或更新工具链上，并且没有用平台验证器的差异结果替代纯 Go 验证。

Go 官方发布说明明确指出，策略验证遵循 RFC 5280 与 RFC 9618，并且只返回策略图有效的证书链。因此更稳妥的修复顺序是：先补齐真实中间证书，再核对 CA 策略扩展，最后收窄 CertificatePolicies；不要为了让请求通过而把策略检查删除。

用固定输入建立回归检查清单

1. 固定 Roots、Intermediates 和 CurrentTime，不要让系统根证书和当前时间造成漂移。
2. 先执行不带策略的基线验证，再执行带一个已知 OID 的策略验证。
3. 记录每条候选链的叶子、各级 CA、策略 OID 和错误类型，不要只记录最终错误文本。
4. 分别覆盖目标 OID 存在、只存在于错误分支、缺少中间证书和策略图断裂四个用例。
5. 若需要兼容 Go 1.23 及更早版本，把策略验证能力作为版本差异明确写进兼容层，而不是静默假设字段存在。

这样定位后，“证书链通过验证却不满足策略 OID”就不再是矛盾：前者回答“谁签发、是否可信、是否过期”，后者回答“这条有效链是否满足证书策略约束”。

常见问题

为什么 CertificatePolicies 写了 OID 仍然失败？

它只是调用方可接受的策略集合，证书链必须真实携带并形成有效策略图；配置不会修改叶子或 CA 证书。

只检查叶子证书的 Policies 可以吗？

不建议。中间 CA 的策略限制会向下影响链，至少要把最终候选链的每一层都打印出来。

Go 1.23 能否直接使用这套代码？

不能按 Go 1.24 的 API 假设处理。应在兼容层区分工具链版本，旧版本需要使用自身可用的验证能力或升级后再启用策略验证。