Go x509 NameConstraints 怎样限制中间 CA 的域名范围

如果 Go 的证书链看起来已经接上了可信根，但验证仍提示域名不被授权，先不要把问题归到 VerifyOptions.DNSName。中间 CA 还可以通过 X.509 的 NameConstraints 限制后续证书能使用的域名范围；信任链成立，不代表每个 SAN 都被允许。

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

最小排查顺序是：先确认 Roots 和 Intermediates 组成了预期链路，再看中间 CA 的 PermittedDNSDomains 与 ExcludedDNSDomains，最后对照叶子证书 SAN 和 Verify 返回的错误类型。

先分清信任链与域名约束

Roots 解决“信任谁”，Intermediates 解决“链路中间缺哪些证书”，而 NameConstraints 解决“这个 CA 允许给哪些名称签发证书”。三者属于不同层次，不能因为根证书已经加入池中，就认为所有下游域名都能通过验证。

Go 的 Certificate.Verify 会把中间证书中的名称约束应用到证书链声明的名称，而不只是 VerifyOptions.DNSName。例如中间 CA 只允许 svc.example.com 的子域，叶子证书 SAN 却声明了 other.example.net，即使调用方验证的 DNSName 没有写成这个名称，链上的名称约束仍然可能使验证失败。

用 VerifyOptions 复现验证边界

排查时先把输入边界写清楚：根证书放入 Roots，非信任锚点的中间证书放入 Intermediates，目标主机名放入 DNSName。下面的函数只展示验证入口和错误分层，不生成或下载真实证书。

func verifyServerCertificate(
	leaf *x509.Certificate,
	roots *x509.CertPool,
	intermediates *x509.CertPool,
	dnsName string,
) error {
	// Roots 是信任锚点，Intermediates 只提供组链所需的中间证书。
	opts := x509.VerifyOptions{
		Roots:         roots,
		Intermediates: intermediates,
		DNSName:       dnsName,
		// 留空 KeyUsages 时，默认按服务器认证用途检查。
	}

	// Verify 会同时处理链路、有效期、用途和中间 CA 的名称约束。
	_, err := leaf.Verify(opts)
	return err
}

这里不要把中间证书放进 Roots 来“绕过”约束。那会改变信任模型，甚至让排查结果与真实服务端链路不一致。要验证某个名称约束是否生效，应保留原本的根与中间证书分工。

检查 NameConstraints 与 SAN

解析中间 CA 后，重点看四组字段：PermittedDNSDomains 表示允许范围，ExcludedDNSDomains 表示明确排除范围，PermittedDNSDomainsCritical 表示扩展是否被标为关键，叶子证书的 DNSNames 则是实际声明的 DNS SAN。Go 还支持 IP、邮箱和 URI 相关的名称约束，但本题只聚焦 DNS。

func describeDNSBoundary(ca, leaf *x509.Certificate) {
	// 这些字段来自证书本身，不能用调用方的 DNSName 代替。
	fmt.Printf("允许域名: %v\\n", ca.PermittedDNSDomains)
	fmt.Printf("排除域名: %v\\n", ca.ExcludedDNSDomains)
	fmt.Printf("叶子 SAN: %v\\n", leaf.DNSNames)

	// NameConstraints 由 Verify 按证书链规则解释，不要手写字符串包含判断。
	// 手工判断容易忽略子域边界、通配符和多个名称同时存在的情况。
}

尤其要注意前导点的语义：官方文档说明，DNS 名称约束中的前导点表示至少还要有一个额外标签。因此把 .example.com 当成“包含 example.com 的任意字符串”是错误的；它表达的是更窄的子域边界。最终结论仍应以 Verify 的链路验证为准。

按错误类型收敛排查

名称约束失败、主机名不匹配和根链路缺失，排查方向不同。可以先保留错误原值，再按类型分支：

func explainVerifyError(err error) string {
	// 先判断证书验证错误，保留 Reason 便于日志和告警聚合。
	var invalid x509.CertificateInvalidError
	if errors.As(err, &invalid) {
		switch invalid.Reason {
		case x509.CANotAuthorizedForThisName:
			return "中间 CA 的名称约束拒绝了链上的名称"
		case x509.IncompatibleUsage:
			return "证书用途与 VerifyOptions 不匹配"
		case x509.NoValidChains:
			return "没有形成可接受的证书链"
		}
	}

	// 主机名错误通常说明叶子 SAN 与 DNSName 不匹配，另行检查 SAN。
	var hostnameErr x509.HostnameError
	if errors.As(err, &hostnameErr) {
		return "叶子证书主机名与 DNSName 不匹配"
	}
	return err.Error()
}

还要记住，Certificate.Verify 不负责吊销检查；如果名称约束已经通过，仍需由独立的吊销或在线状态方案处理那一层问题。

相关问题

只设置 DNSName 能绕过中间 CA 的 NameConstraints 吗？

不能。DNSName 是调用方要验证的主机名，NameConstraints 是证书链中的 CA 对名称范围施加的限制，两者会一起参与验证。

为什么证书 SAN 看起来正确仍然失败？

检查 SAN 是否同时包含了多个名称，以及中间 CA 是否对整条链声明的名称施加了更窄的允许范围。先看 CertificateInvalidError.Reason，不要只看错误字符串。