HTTPS 用 IP 访问仍报 COMMON_NAME_INVALID：SAN 必须是 IP 类型

浏览器已信任内部 CA，用 IP 打开 HTTPS 仍报 NET::ERR_CERT_COMMON_NAME_INVALID；证书的 CN 和 SAN 看上去都写了同一个 IP。先查看 SAN 的类型：DNS:192.0.2.10 与 IP Address:192.0.2.10 是不同标识，数字相同也不能互相替代。

以下针对直接通过 IP 地址访问、由自己管理证书的 HTTPS 服务。使用域名访问时，应按那个域名检查 DNS 类型的 SAN。证书信任、有效期和访问标识匹配分别都需要满足，导入 CA 只能解决其中的信任关系。

比较的是地址栏里的标识

记录实际失败的 URL，包括 HTTPS 后的主机部分，以及浏览器实际收到的证书。域名解析到某个 IP，并不意味着证书必须带那个 IP；如果地址栏是 service.example.com，匹配目标仍是这个域名。

只有地址栏直接使用 IP 时，才检查证书是否包含对应的 IP 类型 SAN。把数字字符串填进 CN，或把它作为 DNS 类型 SAN，都不能代替 IP 标识。现代 HTTPS 客户端不能依赖只写 CN 的旧方式完成服务身份检查。

先确认浏览器取得的证书与准备部署的文件相同。反向代理、不同端口、多节点和默认 TLS 站点可能提供另一张证书；本地文件正确而入口仍返回旧证书时，应修部署与选证书路径。

看 SAN 类型，不只看证书名称

下面是 OpenSSL 3.x 的只读检查示例，路径与 IP 均需替换为实际值：

openssl x509 -in /path/to/server.crt -noout -ext subjectAltName
openssl x509 -in /path/to/server.crt -noout -checkip 192.0.2.10

第一条显示 SAN 扩展，第二条检查这个证书文件是否匹配指定 IP。这里只检查文件，不保证公网入口正在使用它；-checkip 也不是完整的证书链、有效期和浏览器信任验证。

例如，下面是错误类型的示例输出：

X509v3 Subject Alternative Name:
    DNS:192.0.2.10

直接访问这个 IP 时，需要的是 iPAddress 类型，OpenSSL 常显示为 IP Address:192.0.2.10。IPv4 在证书中按四个地址字节编码，IPv6 按十六个地址字节编码，不是把地址字符串塞进 dNSName 就能得到同样含义。

如果 SAN 已有正确 IP，仍报同一错误，继续检查浏览器实际访问的地址、重定向后的目标以及每个服务节点提供的证书，不要重复修改同一份正确文件。

在签发配置中使用 IP，再检查签发成品

如果需要同时通过内部域名和 IP 访问，可在原有签发流程中采用这样的扩展结构：

subjectAltName = DNS:service.example.com,IP:192.0.2.10

这只是 OpenSSL 扩展语法示例，不是完整证书签发配置。按实际 CA、证书管理工具和用途设置所需名称，保留正确的证书用途、链和私钥保护。若使用管理面板，确认填的是 IP 地址类型，而不是只在“域名”列表里加入数字文本。

已经签名的证书不能通过编辑显示内容变成另一种 SAN。需通过认可的 CA 或内部签发流程重新签发，检查最终签发证书中确实保留了这些扩展。CSR 中申请了某项，不保证 CA 最终签出的证书包含它。

如果业务能够稳定使用一个受证书覆盖的域名，也可以把客户端地址、书签和应用配置统一为该域名，并保证其解析指向预期服务。不能只改变 DNS 后继续用旧 IP URL，再期待客户端改成按域名校验。

不要关闭证书校验、用长期忽略浏览器告警的方式“修复”，也不要为解决名称类型问题就把服务器叶证书随意当作系统 CA 导入所有机器。

部署后从原 URL 检查

变更前保存原证书、完整链、私钥引用与服务配置，限制备份的访问权限。按对应服务的流程校验并加载新证书；需要重启时安排连接中断，确认多节点都更新，避免请求轮流落到新旧证书。

从最初失败的 IP URL 再访问，检查实际收到的证书具有正确 IP SAN、信任链有效、日期有效，且原业务请求正常。若改为域名入口，则检查新 URL、重定向与必要的客户端配置都采用同一域名。

回退时恢复经过核对的证书与配置，再按相同方式加载。若原证书本来就缺少正确 IP 标识，回退可能用于恢复其他受支持入口，但不会使原 IP URL 自动变得合格；应保留仍可工作的入口，继续完成正确签发。