证书里的 CN 为什么救不了域名不匹配：SAN 才是真正的校验名单
很多人排查“证书域名不匹配”时盯着 Subject 里的 CN 看，结果越看越糊涂。现代 TLS 客户端早就只看 SAN 扩展，CN 只是个历史遗留标签。本文讲清两者的分工和实际排查时机。
排查“证书域名不匹配”告警时，不少人的第一反应是打开证书看 Subject 那一行：CN = example.com。CN 明明写着对的域名，浏览器为什么还报错？因为浏览器根本没看 CN。它看的是另一个字段——SAN（Subject Alternative Name）。这就像拿着旧通讯录上的地址找搬家后的朋友：名字没错，但没人按这个地址投递了。
CN 和 SAN 的分工
CN（Common Name）是证书 Subject 字段里的一个属性，诞生于 X.509 早期，当时它被顺手用来存放域名。问题是 Subject 的语义本来是“这个实体是谁”，不是“这张证书对哪些域名有效”，而且 CN 只能放一个值。一张证书要覆盖 example.com 和 www.example.com，一个 CN 就捉襟见肘了。
后来 SAN 扩展成为标准做法：它是一个列表，可以写多个 DNS 名称、通配符甚至 IP 地址。CA/B 论坛的基线要求进一步明确了规则——公开信任的证书必须把域名放进 SAN，客户端校验时以 SAN 为准，不再回退到 CN。Chrome 等浏览器从几年前开始严格只查 SAN，如果证书只有 CN 没有 SAN，直接报 ERR_CERT_COMMON_NAME_INVALID，这个错误名字本身就是个历史冷笑话：出问题的其实是 SAN 缺失。
所以现在的实际分工是：
- SAN：校验依据。客户端拿你访问的主机名去匹配 SAN 列表，命中才通过。
- CN：展示和兼容用途。CA 习惯把主域名同时写进 CN，方便人眼看证书时快速识别，但它不参与校验决策。
什么时候会撞上这个问题
签发通配符证书时。 *.example.com 的 SAN 只匹配一级子域名，不匹配 example.com 本身，也不匹配 a.b.example.com。如果 SAN 里只有通配符项，裸域名访问必然失败。签证书时要把 example.com 和 *.example.com 都写进 SAN。
内部 PKI 或老旧系统。 自己用 OpenSSL 签内部证书时，如果只设了 -subj "/CN=internal.local" 而没加 subjectAltName，用 curl 或现代浏览器访问会失败，但某些老客户端反而能过——这种“有的能连有的不能连”的现象，十有八九就是 CN/SAN 差异在作怪。
看证书误读时。 用 openssl x509 -text 查看证书，先别被 Subject 行的 CN 带跑，直接搜 X509v3 Subject Alternative Name 那一段，那才是客户端真正比对的名单。排查不匹配告警时，对照实际访问的域名（注意 SNI 发送的主机名）和 SAN 列表逐项核对。
顺带一提，CN 的值和 SAN 不一致不会造成错误——客户端根本不关心。但如果你依赖 CN 做审计或资产管理，就会拿到错误信息。
在 CertbotX 中实践
签发时在域名参数里把需要的名称一次列全，CertbotX 的 ACME 自动签发会把每个名称都写入 SAN，而不是只生成一个 CN。到期前重新签发会沿用同一份域名列表，避免续期后 SAN 缩水导致部分域名突然报不匹配。部署到 Agent、EdgeOne 或 CDN 后，部署记录会保留每次推送的证书信息，排查“哪个环境还挂着旧证书”时可以直接翻审计记录对照 SAN。
