“名称不匹配”或“NET::ERR_CERT_COMMON_NAME

“名称不匹配”或“NET::ERR_CERT_COMMON_NAME_INVALID”错误的直接原因与修复路径

该错误表明浏览器在 TLS 握手过程中验证证书 subjectAltName（SAN）字段时失败，**证书未覆盖当前访问的域名**。自 RFC 6125 和 CA/B Forum Baseline Requirements v1.7.1 起，commonName（CN）字段已完全弃用，浏览器仅依据 SAN 字段执行主机名匹配。若证书 SAN 中缺失请求域名、包含拼写错误、使用了 IP 地址但未显式声明，或通配符作用域越界（如 *.example.com 不匹配 sub.sub.example.com），均触发此错误。该问题与证书签名算法、私钥强度、有效期或信任链完整性无关，属于纯域名覆盖性缺陷。

请确认您正在访问的域名是否与证书中列出的 DNS 名称完全一致（区分大小写、不含端口、不含路径）。

典型触发场景与验证方法

访问 www.example.com 但证书 SAN 仅含 example.com：不匹配 - 使用 HTTPS 访问内网 IP（如 https://192.168.1.100）但证书未将该 IP 列入 SAN：不匹配 - 部署通配符证书 *.example.com 后访问 api.example.com（合法） vs dev.api.example.com（非法）：后者不匹配 - 证书由旧系统签发且仅填充 CN 字段、未设置 SAN：所有现代浏览器拒绝可通过 OpenSSL 命令快速验证：openssl x509 -in cert.pem -text -noout | grep -A1 "Subject Alternative Name"

不可行的临时规避手段

修改客户端 hosts 文件或 DNS 解析：不解决证书本身缺陷 - 在 Chrome 中点击“高级 → 继续前往…”：仅绕过单次验证，不适用于生产环境、PWA、Service Worker 或 WebView 容器 - 启用 TLS 1.0/1.1 兼容模式：该错误发生在证书验证阶段，与协议版本无关

工程修复步骤

首先确认 Web 服务器配置中实际加载的证书文件路径是否正确（常见于 Nginx 的 ssl_certificate 指令指向过期或错误文件）。其次检查证书 SAN 是否完整覆盖全部接入域名（含 www/non-www、API 子域、CDN 回源域名等）。最后重新部署并使用 ssl证书工具验证终端实体证书的 SAN 字段与服务暴露域名的一致性。若需覆盖多个独立域名（如 example.com、blog.org、app.io），应选用多域名SSL证书；若需覆盖同一主域下任意一级子域，应选用通配符证书；若仅需单个精确域名，可选用单域名SSL证书。

维度	参考标准	工程师建议
域名匹配逻辑	RFC 6125 Section 6.4.1；CA/B BR §7.1.4.2	必须严格比对 SAN 中的 dNSName 条目，不支持隐式继承或正则匹配
通配符有效性	CA/B BR §7.1.4.2.1	仅匹配单级子域（`*.example.com`≠`sub.dev.example.com`）
IP 地址支持	RFC 6125 §7.4；CA/B BR §7.1.4.2.2	仅当 SAN 显式包含 iPAddress 条目时才允许匹配，且必须为规范格式（IPv4 无前导零，IPv6 压缩格式）

常见问题

Q：我用了通配符证书 *.example.com，为什么访问 api.example.com 正常，但 dev.api.example.com 报错？ A：通配符仅覆盖一级子域，dev.api.example.com 属于二级子域，需额外添加该域名至 SAN，或改用更宽泛的通配符（如 *.*.example.com 不被任何 CA 支持）或采用多层级证书策略。

Q：证书在 OpenSSL 命令中显示 SAN 正确，但浏览器仍报错？ A：检查服务器是否启用 SNI（Server Name Indication），确保虚拟主机配置未回退到默认证书；同时确认 CDN 或反向代理（如 Nginx、Cloudflare）未缓存旧证书或注入中间证书。

Q：能否通过修改证书 CN 字段来修复？ A：不能。Chrome、Firefox、Safari 自 2017 年起完全忽略 CN 字段进行主机名验证，仅依赖 SAN。