Go 证书主机名校验失败时应该查 SAN 还是 CN

遇到 Go 的 x509: certificate is valid for ... 或“证书依赖旧式 Common Name”错误，第一眼应该查 SAN，而不是先改 CN。对 DNS 主机名，crypto/x509 的 VerifyHostname 查的是证书的 DNSNames；对 IP 地址，查的是 IPAddresses。传统 Subject.CommonName 已不再作为正常的主机名匹配依据。自定义 CA 只解决“我是否信任签发者”，不能把一个不包含目标主机名的证书变成匹配证书。

先把主机名校验拆成 SAN、CN 和信任链

可以把这类错误分成两条独立路径：证书链是否能被信任，以及叶子证书是否允许当前主机名。Go 的 VerifyHostname 会把普通名称与 DNSNames 比较，把 IP 与 IPAddresses 比较，通配符也只按合法的最左标签处理。它不会把 Subject.CommonName 当成现代证书的兜底字段。

因此，证书里只有 CN=api.internal.example 而没有 SAN 时，即使浏览器或旧客户端曾经接受，当前 Go 客户端仍可能返回 x509: certificate relies on legacy Common Name field, use SANs instead。这不是 CA 证书池为空，而是名称字段过时。

从错误信息判断应该查哪一层

先看错误关键词，能避免把证书问题和信任问题混在一起：

把证书内容打印出来时，重点看 Subject Alternative Name，不要只看 Subject：

# 只查看 SAN 和 Subject，避免把 CN 误当成主机名校验依据
openssl x509 -in server.crt -noout -ext subjectAltName -subject

如果调用地址是 https://10.20.0.15，证书必须有对应的 IP SAN；写成 DNS:10.20.0.15 也不等价。若调用地址是 api.internal.example，则应出现 DNS:api.internal.example 或符合规则的通配符。

自定义 CA 正确了，为什么仍然会报主机名错误

RootCAs 只影响“信任谁”。客户端还会从 tls.Config.ServerName 得到要校验的名称；普通 HTTPS 请求通常由连接地址推导它，但代理、内网别名或自定义拨号器场景可能让两者不一致。下面的配置只适用于 CA 私有、且证书 SAN 已经正确的内网服务：

package main

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

func tlsConfig(caPEM []byte) (*tls.Config, error) {
	// 将私有 CA 加入信任池，不改变主机名匹配规则。
	roots := x509.NewCertPool()
	if !roots.AppendCertsFromPEM(caPEM) {
		return nil, fmt.Errorf("私有 CA 不是有效 PEM")
	}
	return &tls.Config{
		RootCAs:    roots,
		ServerName: "api.internal.example", // 必须能在 DNS SAN 中匹配
		MinVersion: tls.VersionTLS12,
	}, nil
}

示例中的 fmt 需要补充导入；这里故意把错误当成启动配置错误返回，而不是继续使用空的根证书池。生产环境不要通过 InsecureSkipVerify: true 绕过名称校验，否则链路加密仍在，服务端身份却没有被确认。

修复证书后用同一条请求路径复查

修复时优先重新签发证书：DNS 服务使用 DNS SAN，固定 IP 或直接访问 IP 时加入 IP SAN；如果一个服务有多个入口，把实际使用的别名一起放入 SAN。然后保持请求地址、代理设置、ServerName 和服务端证书的一致，重新观察原始错误是否消失。

如果名称错误消失却变成 unknown authority，说明 SAN 已经匹配，下一步才是补齐 RootCAs 或检查中间证书。反过来，补 CA 后仍报 valid for，就不要继续改证书池，而应回到 SAN 和 ServerName。Go 官方 crypto/x509 文档和crypto/tls 文档分别说明了名称校验与 TLS 配置的职责。

常见问题

CN 和 SAN 都写了同一个域名，应该看哪个？

看 SAN。现代 Go 的主机名校验以 DNS SAN 或 IP SAN 为准，CN 最多用于识别证书是不是旧格式。

自定义 CA 能不能解决证书名称不匹配？

不能。CA 解决签发者信任，名称不匹配必须调整证书 SAN、请求地址或 ServerName。

测试环境可以临时打开 InsecureSkipVerify 吗？

只应在隔离测试中明确标注并尽快移除；它会跳过证书链和主机名验证，不是生产修复方案。

判断顺序可以固定为：先确认请求的到底是域名还是 IP，再看对应 SAN，之后检查 ServerName，最后处理 RootCAs 和中间证书。这样查证书主机名错误时，就不会在 CN、CA 和 TLS 开关之间来回试错。