Go crypto/x509 CertPool.AddCertWithConstraint 怎样限制证书链验证范围

我在给多租户服务接入自定义根证书时，最容易误解的一点是：把证书放进同一个 CertPool，并不等于已经表达了“这个根证书只能服务某个租户”。Go 的 crypto/x509 提供了 CertPool.AddCertWithConstraint：它把回调绑定到指定根证书，Certificate.Verify 构建出以该根为终点的链时，会把整条链交给回调；回调返回非空错误，这条链就会被丢弃。

这个方法从 Go 1.22 起出现在标准库中。它适合做应用层的证书链附加约束，例如只接受某个租户域名，不负责证书签发，也不替代撤销检查。

把约束挂在根证书而不是 VerifyOptions 上

我实际使用时会先把规则归属想清楚：AddCert 只负责把证书放入池中；AddCertWithConstraint 多接收一个 func([]*x509.Certificate) error。因此约束的归属不是一次性的 Verify 调用，而是“某个根证书参与建链时”的规则。

例如根池里同时有平台根证书和租户根证书时，我只给租户根证书注册约束。平台根证书构建出的链不会自动进入这条回调，调用方仍要根据自己的信任边界决定是否允许它。

约束函数怎样读取链并拒绝不符合范围的证书

回调拿到的是完整链。Verify 成功返回的链首元素是叶子证书，末元素是 Roots 中选中的根证书，中间元素是建链使用的中间证书。我的经验是让回调只读取这些证书的公开字段，并返回稳定、可记录的错误。

package certscope

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

// bindTenantRoot 把租户域名范围绑定到指定根证书。
func bindTenantRoot(pool *x509.CertPool, root *x509.Certificate, suffix string) {
    pool.AddCertWithConstraint(root, func(chain []*x509.Certificate) error {
        // Verify 的链首是叶子证书；空链属于无法判断的输入。
        if len(chain) == 0 || chain[0] == nil {
            return errors.New("证书链为空，拒绝使用租户根证书")
        }

        // 只读叶子证书的 SAN，避免把证书链对象改成共享可变状态。
        for _, name := range chain[0].DNSNames {
            if strings.HasSuffix(name, suffix) {
                return nil
            }
        }
        return errors.New("叶子证书不在租户域名范围内")
    })
}

上面的 suffix 应由业务配置明确给出，例如 .tenant.example，而不是从请求参数直接拼接信任规则。真实项目还应明确是否允许根域本身、IP SAN 或通配符，不能把字符串后缀比较当成完整的证书策略。

把约束池交给 Verify

注册约束后，验证入口仍然是普通的 Certificate.Verify。根证书池通过 Roots 传入，中间证书放在 Intermediates；DNSName 继续承担主机名校验，回调则承担额外的业务范围校验。

func verifyLeaf(leaf *x509.Certificate, roots, intermediates *x509.CertPool) error {
    // DNSName 校验主机名，Roots 中的回调校验额外业务边界。
    _, err := leaf.Verify(x509.VerifyOptions{
        Roots:         roots,
        Intermediates: intermediates,
        DNSName:       "api.tenant.example",
    })
    if err != nil {
        // 保留 Verify 的原始错误，便于区分建链失败与业务约束拒绝。
        return err
    }
    return nil
}

如果同一根池里存在另一条可行链，Verify 可能继续尝试其他链；回调拒绝的是“以该根证书为终点的当前候选链”，不是无条件拒绝整个叶子证书。因此我会先梳理根池的信任边界，而不是把所有根都混在一起后再期待回调完成租户隔离。

并发与边界：回调要保持只读

官方文档明确提示约束回调可能被多个 goroutine 并发调用。不要在闭包里累加未加锁的计数器、修改共享切片或复用带写入状态的错误对象；如果必须记录命中次数，应使用并发安全的指标组件，或者把统计放在 Verify 调用外层。

我最后保留的判断很简单：把根证书放入池时就绑定约束，回调只读整条链并返回明确错误，验证时再把这个池交给 Verify。这样标准链验证和业务信任边界各自清楚，后续排查也不容易把主机名错误、建链错误和业务拒绝混为一谈。

相关问题

Q：AddCertWithConstraint 会修改证书本身吗？
不会，它把证书和约束关系放入 CertPool；回调应把证书视为只读输入。

Q：回调返回错误后一定不会尝试别的链吗？
不应这样假设。它会丢弃当前以该根为终点的链，Verify 的整体结果还取决于根池和中间证书能否形成其他有效链。

Q：它能替代证书吊销检查吗？
不能。Verify 文档明确说明它不执行撤销检查，撤销状态需要独立接入。