CN 和 SAN 的区别 - 极速工具箱

部署完 HTTPS 之后，浏览器仍然报「证书名称不匹配」。打开证书一看，CN 里写的正是要用的域名，为什么还报错？原因在于，现代浏览器判断域名覆盖时只看 SAN，完全忽略 CN。如果 SAN 里没有这个域名，CN 写得再对也没用。

两个字段的来历

CN（Common Name，通用名称）是早期证书里表示域名的字段。它的设计假设是「一张证书对应一个域名」，所以只需要一个字段就够了。

但随着需求发展，这个假设被打破了。一个站点可能有多个域名（主域名、别名域名、CDN 域名），也可能需要覆盖多个子域名。一个 CN 字段无法表达这些。

于是 SAN（Subject Alternative Name，主体备用名称）被引入。它是一个列表字段，可以包含多个域名和 IP 地址。

从很多年前开始，主流浏览器就改变了判断逻辑：只检查 SAN，完全忽略 CN。

这意味着：

如果证书的 SAN 列表里包含你要访问的域名，浏览器就认为匹配——即使 CN 里写的是别的域名，甚至 CN 是空的。

如果 SAN 列表里没有这个域名，浏览器就报名称不匹配——即使 CN 里写的是这个域名。

这个变化是渐进的。早期浏览器会先看 SAN，SAN 不存在时回退到 CN。后来的版本逐步取消了回退，现在即使 SAN 为空也不再使用 CN。

所以在排查证书问题时，第一步是看 SAN 列表，而不是看 CN。很多证书的 CN 和 SAN 第一项是同一个域名（因为申请时通常这么配置），这让人误以为 CN 在起作用，实际上起作用的是 SAN。

SAN 里可以使用通配符，但要理解它的匹配范围。

*.example.com 只匹配一级子域名。

匹配：www.example.com、api.example.com、a.example.com
不匹配：a.b.example.com、example.com 本身

两个容易踩的点。

第一，通配符不匹配多级子域名。如果站点有 a.b.example.com 这样的三级域名，*.example.com 覆盖不了它，需要单独加到 SAN 里。

第二，通配符不匹配裸域名。*.example.com 不覆盖 example.com，需要把裸域名单独列进 SAN。

另外，通配符只能出现在最左侧的标签位置。www..com 或 example. 这类写法是不被支持的。

方法很直接：找到证书的 SAN 列表，逐项比对。

完全匹配：SAN 里有 api.example.com，访问的就是 api.example.com，匹配。

通配符匹配：SAN 里有 *.example.com，访问的是 www.example.com，匹配（因为 www 是一级子域名）。

不匹配：SAN 里有 *.example.com，访问的是 a.b.example.com，不匹配（多了一级）。

比对时要注意大小写不敏感——域名比较通常不区分大小写。

情况一：申请证书时只填了 CN，没填 SAN。这种情况在早期的证书申请流程里可能出现，但现在的 CA 基本都会自动把 CN 的值也放进 SAN。如果遇到 SAN 为空的老证书，唯一的解决办法是重新签发。

情况二：域名加了新的子域名，证书没更新。比如证书申请时只有 www 和裸域名，后来加了 api 子域名，但证书没重新签发。这时访问 api.example.com 就会报名称不匹配。解决办法是重新签发包含新域名的证书。

情况三：用的是通配符证书，但访问的是三级域名。通配符只覆盖一级，三级域名需要额外添加。

情况四：CDN 或负载均衡上的证书没更新。如果站点前面有 CDN，证书可能同时存在于源站和 CDN 节点上。更新了源站但没更新 CDN，用户访问时看到的仍然是旧证书。

遇到「证书名称不匹配」时，建议按这个顺序检查。

第一步，看浏览器提示的详细信息，确认它认为证书覆盖了哪些域名。

第二步，解析证书，查看 SAN 列表的完整内容。

第三步，把要访问的域名与 SAN 列表逐项比对，注意通配符的层级限制。

第四步，如果确实不覆盖，确认是需要重新签发证书，还是需要调整访问的域名。

第五步，如果证书本身没问题，检查是否有 CDN 或反向代理在中间返回了不同的证书。