openssl s_client -servername 缺失时证书为何变化

openssl s_client 缺少显式 -servername 时证书变化，常见原因是同一 IP 承载多个 TLS 站点，服务端依据 ClientHello 中的 SNI 选择不同证书。不过“没写参数”不一定等于“没发送 SNI”：OpenSSL 1.1.1 起，若 -connect 使用 DNS 名称格式，默认会用该名称填入 SNI。要比较真正无 SNI 的行为，应显式使用 -noservername。

官方文档：https://docs.openssl.org/3.5/man1/openssl-s_client/

规模背景：多个域名可以共享一个 TLS 入口

假设一个反向代理入口同时承载 api.example.test 与 files.example.test。客户端连接的是同一个地址，但希望访问的逻辑站点不同。共享入口需要在 TLS 握手阶段知道目标名称，才能决定采用哪个站点配置及证书。

这个名称选择发生在 HTTP 请求之前。不能指望稍后添加的 Host 请求头修正已经返回的 TLS 证书。本文使用保留示例域名与文档 IP 说明架构，没有声称对任何实际站点执行了握手。

原架构的局限：只凭 IP 不足以唯一确定站点

如果一个 IP 只有一份证书，是否携带 SNI 可能暂时看不出差别；扩展为多站点共享后，默认站点配置就会影响无名称客户端。此时“连接成功”与“拿到目标站点证书”是两件事。

无 SNI 时，服务端可能返回默认配置的证书，也可能拒绝握手；不应断言它一定返回“第一张证书”。具体结果由服务端策略决定。如果默认策略正好使用同一份多域名证书，两次结果也可能相同，不能反推 SNI 没有发送。

新架构：用 SNI 区分网络目的地与逻辑站点

-connect 决定到哪里建立连接，-servername 决定在 TLS ClientHello 里表达哪个名称。它们可以有意不同：连接固定入口 IP，同时发送目标服务域名，适合排查某个入口节点的站点证书配置。

由于当前工具会从 DNS 形式的 connect 目标自动填入 SNI，对比时必须明确参数。使用域名连接但删掉 servername，可能根本没有移除扩展；使用 IP 连接再删掉参数，则可能改变实际发送的名称。两种命令不能只按参数数量归为同一类。

关键取舍：固定入口，只改变 SNI

下面的命令需要替换成自己管理的入口和域名，属于供读者执行的诊断示例，本文没有运行。固定 IP 有助于减少 DNS 解析到不同节点这一变量，但同一个 IP 背后仍可能有多台后端或证书轮换。

# 示例地址属于文档保留范围；替换为你管理的实际入口与域名。
# 两次固定同一 IP，只改变是否发送 SNI；交互时可用 Ctrl+C 结束。
openssl s_client -connect 192.0.2.10:443 -servername api.example.test -showcerts

# 显式禁止 SNI，避免把省略参数误当成没有扩展。
openssl s_client -connect 192.0.2.10:443 -noservername -showcerts

两条命令分别是“指定 SNI”和“明确不发送 SNI”，不是“验证成功”和“验证失败”的一对命令。握手若被拒绝，应保留错误信息；不能把没有证书的失败当作证书字段为空。对照还应保持协议选项与其他客户端能力一致，避免同时改变多项条件。

需要判断是否同一张叶证书时，可将对应 PEM 块完整保存后查看指纹、序列号、有效期与 SAN：

# 将目标握手中的叶证书 PEM 完整保存为 leaf.pem，再查看身份与指纹。
openssl x509 -in leaf.pem -noout -subject -issuer -serial -dates -fingerprint -sha256 -ext subjectAltName

不要只比较 subject 的文字。证书轮换可能保留相似名称，但指纹与序列号不同；同一份证书也可能通过 SAN 覆盖多个名称。比较前应确认取的是叶证书，而不是链中的某个中间证书。

结果判断：证书选对，还需要验证身份与信任

-showcerts 显示服务端发送的证书列表，不表示它已经是一条经过验证的可信链。s_client 本身是诊断工具，默认可以在报告证书验证错误后继续握手。不能仅凭看到证书或 CONNECTED 字样就宣布目标身份验证通过。

若目标是检查服务证书是否满足预期名称及信任要求，应分别指定验证目标，并要求遇到验证错误时返回失败：

# 证书选择与身份校验分别指定；trusted-ca.pem 为实际可信 CA 文件。
openssl s_client -connect 192.0.2.10:443 -servername api.example.test -verify_hostname api.example.test -verify_return_error -CAfile trusted-ca.pem

trusted-ca.pem 必须替换为该场景真实可信的 CA 材料，而不是从刚收到的服务器证书随意制作信任文件。这里 verify_hostname 检查域名身份，servername 仍负责发出 SNI；它们即使写成相同字符串，职责也不同。实际访问以 IP 为身份目标时，需要按证书中的 IP 身份与相应验证选项设计，不能只把域名参数换成数字。

以上命令展示的是判断方法，没有提供虚构的上线成功结果。非交互调用还要考虑标准输入结束导致连接提前退出的情况；若用 ign_eof 保持连接，则需要配套明确的协议结束方式和外部等待上限，避免脚本一直等待。不要把空输出简单等同于服务端没有配置证书。

后续改进：把入口、名称和版本写进排查记录

多人协作时，记录 connect 地址、发送的 SNI、OpenSSL 版本和叶证书指纹，比一句“证书不对”更容易定位。规模化入口还应让无 SNI 的默认策略明确可维护，而不是依赖配置加载顺序碰巧选中一张证书。

常见问题

删掉 -servername 为什么证书没有变化

可能仍从 DNS 格式的 connect 目标自动发送 SNI，也可能入口给两种请求使用了同一份证书。显式 noservername 才能表达不发送扩展。

给 HTTP Host 头能补救吗

不能改变当前握手已经选出的证书。HTTP 路由和 TLS 证书选择属于不同阶段的协议职责。

证书变化一定代表部署错误吗

不一定。共享入口按名称提供不同证书是正常设计；要结合预期站点、SAN、入口节点及验证结果判断，而不是只看两次输出是否相同。

参考资料

• OpenSSL s_client：SNI 默认值与验证选项
• OpenSSL x509：证书身份和指纹显示
• RFC 6066：TLS server_name 扩展