证书受信仍报主机名不匹配，网关怎样核对连接名与SAN

根CA受信仍然报证书主机名不匹配，并不矛盾：信任签发者与确认连接对象是两项检查。本文创建专用测试CA和只含upstream.test这一DNS SAN的叶证书，保持信任链不变，只改变server_hostname，在回环TLS中实际比较。

让实验只改变连接身份

物理连接始终到127.0.0.1随机端口，客户端只信任实验根证书，并保持主机名校验开启。第一轮声明连接身份upstream.test，握手成功且收到ok；第二轮声明other.test，校验失败；第三轮声明127.0.0.1，同样失败。DNS SAN没有包含IP SAN，连接到回环并不会自动让证书对该IP有效。

这里把网络拨号地址与待验证身份明确分开，避免为了让测试域名解析而改系统hosts。生产中SNI、HTTP Host与证书验证名称也可能分别配置，应核对真实库的行为。把Host头改成证书名字，不能自动修复TLS发生在更早阶段的身份校验问题。

从失败原因寻找正确修复位置

如果本来就应该通过upstream.test访问，应让配置中的验证名称与该服务身份一致，并核对DNS或受控连接方式；如果确实要通过IP作为身份访问，则需要证书包含相应IP SAN。不要把关闭check_hostname或verify=False当作修复，那会删除本次想要验证的边界。

测试CA、叶证书和私钥只在临时目录生成，结束后清理，没有修改系统信任库，也没有把私钥放进公开样本。证书有效期专门覆盖实验日期，避免把到期错误与名称错误混在一起。重跑时密钥和序列号会变化，但三项允许结果应保持真、假、假；证书字节不需要固定。

明确实际验证环境与剩余边界

此次使用Python 3.12.4，底层OpenSSL 3.0.14，连接仅发生在本机回环。Python ssl官方文档区分证书链验证与主机名检查，本实验实际执行了二者共同开启时的三次握手。它没有证明任何真实域名证书正确，也没有验证证书吊销、生产负载均衡的SNI选证或中间代理信任设置。

迁移到网关时，先记录实际连接名称、证书SAN和信任来源，再分别核对链与名称；不要只截取证书“由谁颁发”这一行。若使用自己的CA，应按组织信任流程配置到该服务，而不是随意扩大整机信任。保留同链不同名的负例，能确保未来升级HTTP库后仍然拒绝错误身份，成功路径也有同等明确的证据。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C025。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

证书实验需本地已安装cryptography；私钥只在临时目录生成，实验结束即清理，公开附件不包含私钥。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文只要求HTTPS；本文用本地CA证书验证DNS名/IP与SAN的匹配，和爱奇链客户端内网证书排错不同，受众是部署本机上游TLS的网关维护者。