err_cert_common_name_invalid 实际源于证书 san 字段缺失或不匹配，而非 cn；需用 openssl 验证真实返回证书的 san 是否覆盖访问域名，并确保 nginx server_name、sni 和证书配置三者严格对齐。
证书报错 ERR_CERT_COMMON_NAME_INVALID 表面看是 CN（Common Name）不匹配，实际根源几乎都在 SAN（Subject Alternative Name）字段缺失或不一致。Nginx 本身不校验 CN 或 SAN，但客户端（浏览器、HttpClient 等）会严格检查：访问的域名必须出现在证书的 SAN 列表中，CN 已基本被忽略。
确认当前返回的是哪张证书
别只看配置文件里写了什么路径——Nginx 可能因 SNI 匹配失败、server_name 未覆盖、默认 server 块优先等原因，返回了错误的证书。先验证真实响应：
- 用
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com连接，观察输出中的subject=和Certificate chain部分 - 重点看
-----BEGIN CERTIFICATE-----后的实际证书内容，再用openssl x509 -text -noout解析它，而不是磁盘上你认为“该用”的那张 - 如果返回的是默认站点证书（比如宝塔面板的 default.conf 或 nginx 自带的 default ssl），说明 SNI 没对上，要回头检查
server_name和域名解析是否一致
检查证书 SAN 是否完整覆盖访问域名
现代 HTTPS 验证只认 SAN，CN 不起作用。即使 CN 是 www.example.com，若 SAN 里没有它，照样报错。
- 执行：
openssl x509 -in /path/to/your.crt -text -noout | grep -A1 "Subject Alternative Name" - 输出应类似：
DNS:example.com, DNS:www.example.com, DNS:api.example.com - 注意：通配符
*.example.com不覆盖example.com（根域），也不跨级匹配dev.api.example.com；每个需访问的域名都得显式列出或由正确层级的通配符覆盖 - 用 IP 访问？证书 SAN 必须包含对应 IP 条目，如
IP:192.168.1.100，仅写 DNS 名无效
核对 Nginx server 块与域名绑定逻辑
证书再全，没被正确加载到对应 server 块，也白搭。尤其在多站点共用 443 端口时（如宝塔），容易“张冠李戴”：
- 确认
server_name指令值和用户实际访问的 Host 头完全一致（大小写、www 前缀、端口隐含等） - 检查配置中是否有多个
server块监听同一端口且server_name重叠或缺失，导致 Nginx 选错块 - 宝塔用户特别注意：“SSL”页签中证书绑定的域名列表，必须和「域名管理」里该站点实际配置的
server_name完全一致；删了子域名但没解绑证书，就可能被复用到其他站点 - 反向代理场景下，若后端也要校验证书（如
proxy_pass https://...），还需设proxy_ssl_name "backend-domain.com"，且该值必须和后端证书 SAN 完全匹配
验证证书链是否完整
证书链断裂虽不直接导致 CN/SAN 冲突，但会让客户端无法完成信任链校验，进而跳过域名检查直接报“不可信”，掩盖真实问题：
- 用
openssl s_client -connect domain.com:443 -showcerts查看返回的完整证书链 - 确保证书文件（
ssl_certificate指向的 .pem）里按顺序包含：站点证书 + 所有中间证书（不含根证书） - 常见错误：只放了站点证书，漏了 Let’s Encrypt 的 R3 或 ISRG Root X1 中间件；或顺序颠倒
- 可用 SSL Labs Test 在线验证链完整性与域名覆盖情况
