为什么 SSL 证书与域名不匹配？SAN、通配符与 SNI 排查
SSL 证书与域名不匹配，未必是证书申请错了：访问的名字、SAN、通配符层级、SNI、DNS、CDN 和负载均衡都可能让客户端拿到另一张证书。本文给出从浏览器错误到实际 TLS 入口的排查方法。
浏览器提示证书不匹配，最常见的误会是「这张证书肯定申请错了」。有时确实如此，但更多时候证书本身没有问题：用户访问的是另一个名字，服务器因为缺少 SNI 送出了默认证书，或 DNS 把一部分流量带到了仍在使用旧证书的入口。
排查这类问题要同时回答两个问题：用户请求的到底是哪一个主机名？公网 TLS 端点实际回了哪一张证书？把这两件事拆开，NET::ERR_CERT_COMMON_NAME_INVALID 之类的错误就不再神秘。
先用 SSL 证书检测工具对公网域名做握手检查。它能显示主机名是否匹配、服务端返回的链，以及解析到的地址；随后用 证书解码工具读出证书里的 SAN 列表。
域名覆盖看 SAN，不看文件名或 Common Name
现代客户端以 Subject Alternative Name（SAN）扩展判断证书覆盖哪些名字。Common Name 仍可能显示在证书中，但它不应作为域名覆盖的依据；文件名、订单名称和控制台里的备注当然更不能说明问题。
拿到公网返回的叶子证书后，逐项比较 DNS SAN 与用户地址栏里的完整主机名。不要只确认「公司主域名大概在里面」，要确认字面上请求的那个名字确实被覆盖。
| 请求的地址 | 需要的覆盖 | 常见误解 |
|---|---|---|
example.com | example.com 这个 DNS SAN | *.example.com 会覆盖根域名 |
www.example.com | www.example.com 或匹配它的通配符 | 根域名证书自动覆盖 www |
api.example.com | api.example.com 或 *.example.com | 任意多层通配符都通用 |
v2.api.example.com | 精确 SAN 或 *.api.example.com | *.example.com 可以跨两层 |
https://203.0.113.10/ | 对应的 IP SAN | DNS SAN 能覆盖 IP 访问 |
通配符只替代一层标签
*.example.com 可以覆盖 api.example.com，却不覆盖 example.com，也不覆盖 v2.api.example.com。星号只替代点号之间的一层标签，不是「这个域名下全部层级」的通行证。
因此，申请证书前应从真实入口清单出发：根域名、www、API、管理后台、地区子域名和监控使用的主机名分别列出来。把目前没上线但即将切流的名字也纳入续期和替换计划，避免迁移当天才发现 SAN 少了一项。
SNI 决定服务器先挑哪一张证书
一台 IP 可以承载很多 HTTPS 域名。TLS 握手早于 HTTP 请求，服务器此时还看不到完整的 URL 路径；客户端通过 SNI 告诉服务器「我要访问哪个主机名」，服务器据此选择对应的证书。
如果测试时只连 IP、监控没有携带 SNI，或代理把 SNI 改成了别的名字，服务端通常会返回默认站点的证书。那张证书可能完全有效，只是与用户本来想访问的域名不匹配。
在检测工具中使用真实的主机名，并在按 IP 测试时显式填写预期 SNI。对同一个 IP 分别带和不带目标 SNI 比较：返回证书不同，说明证书选择会随请求或节点变化；带上正确 SNI 仍返回错误证书，才应检查该虚拟主机、Ingress 或负载均衡规则。
DNS、CDN 和负载均衡可能把流量送到旧入口
即使 SAN 配置正确、SNI 也正确，用户仍可能连到另一台机器。迁移或换证书后最常见的是 IPv4 已更新、IPv6 仍指向旧服务，或者 CNAME 前面接入了 CDN、托管平台和多层负载均衡。
用 DNS 查询工具核对 A、AAAA、CNAME 和 TTL，并顺着 CNAME 看清实际入口。低 TTL 不能让所有递归缓存立即忘掉旧记录；它只限制缓存从收到结果开始还能保存多久。出现间歇错误时，要分别检查每个解析结果和每个后端节点。
证书在磁盘上正确，不代表公网在用它
很多排查停在「我服务器上的证书 SAN 没问题」。但真正对外终止 TLS 的可能是 CDN、云负载均衡、Kubernetes Ingress、反向代理，甚至一台忘记退出的旧服务器。后端机器的配置正确，只能证明后端正确。
应以公网握手返回的叶子证书序列号或 SHA-256 指纹为准，再沿着流量路径找到相同或不同的终止点。若某个入口仍送出旧证书，就在那个入口更新配置、重新加载，并从公网验证结果，而不是继续改应用服务器。
域名形式也会改变匹配结果
用户有时并没有访问你认为的标准地址：可能输入了裸 IP、旧域名、内部别名，或复制了带有拼写差异的主机名。IDN 域名在证书和 DNS 中通常以 Punycode 表示，排查时应比较实际握手使用的主机名，而不是只看界面显示。
证书匹配只解决「请求名称是否被证书覆盖」。如果证书正确、链也可信、却只有某个网络显示陌生证书，还要排除企业 HTTPS 检查、门户网络和安全软件在中间替换证书。
一套从错误到修复的排查顺序
- 记录浏览器或客户端提示的完整主机名与错误，不要只记「证书不匹配」。
- 用 SSL 证书检测工具检查该公网主机名，并在需要时指定端口和 SNI。
- 用 证书解码工具查看公网叶子证书的 DNS SAN，逐项与请求主机名比较。
- 检查根域、www、通配符、多级子域和 IP 访问是否被正确覆盖。
- 对同一 IP 比较带与不带预期 SNI 的证书，再检查 CDN、负载均衡或 Ingress 的域名路由。
- 用 DNS 查询工具检查 A、AAAA、CNAME 和所有可能的入口，确认没有旧节点继续送错证书。
- 修复实际 TLS 终止点后，从公网再次握手，并在 IPv4、IPv6 与原先失败的客户端上复测。
如果域名匹配已经通过、但客户端仍不信任链，就不要继续改 SAN。下一步应排查为什么证书链不完整；更完整的决策树见SSL 证书为什么无效。