背景 链接到标题 因为产品中的 HTTPS 所用证书是自签发证书，不满足一些场景的安全要求，需要导入用户证书。本身这个变更很容易，只需要按照Nginx 官方文档 配置下指定证书即可，但遇到了一个特殊的场景：集群存在3个节点，每个节点用户配置了相应的 Domain Name，其中集群中存在 VIP(Virtual IP Address) ，用户给对应的 VIP 配置了相应的 Domain Name。用户在签发证书时，使用的 CN(CommonName) 是 VIP 对应的 Domain Name，subjectAltName 是集群中3个节点的 Domain Name。此时如果通过各个节点相应的 Domain Name 访问，证书有效，但是通过 VIP 对应的 Domain Name 访问，证书无效（因环境特殊，未能看到具体错误提示）。 印象中 CommonName 必须指定对应的 Domain Name，subjectAltName 是 CommonName 的补充，所以这个现象感觉不合理，然后查阅了相关资料进行调查。 GPT4 链接到标题 在调查之前，按照现在的主流操作，遇事不决先问 GPT，于是得到了如下答复，也符合我的理解： 问： 在 https 证书中，如果 CommonName 一定存在于 SubjectAltName 中么？如果同时存在 CommonName 和 SubjectName ，使用哪个作为唯一标识校验？ 答： 在HTTPS证书中，CommonName（CN）和Subject Alternative Name（SAN）是用于标识证书所表示的域名的字段。在早期的SSL/TLS证书中，CommonName通常用于表示证书关联的单个域名。然而，随着时间的推移，Subject Alternative Name扩展被广泛采用，它允许证书关联多个域名和子域名。 从技术上讲，CommonName不一定需要出现在Subject Alternative Name列表中。但是，实际上，许多现代浏览器和客户端会首先检查Subject Alternative Name字段，如果没有找到匹配的域名，才会检查CommonName字段。因此，为了确保证书的兼容性和正确性，建议将CommonName包含在Subject Alternative Name字段中。