使用openssl s_client测试HTTPS服务器出现SSL握手失败的排查指南

这是真实的连接故障，意味着TLS握手流程执行失败，不属于误报。
输出中的三级证书链verify return:1仅代表openssl本地完成了对服务器返回证书链的合法性校验，不代表握手流程已完成。实际流程为：

1. TCP层已经建立连通（输出有CONNECTED(00000003)标识）
2. 客户端发送ClientHello，收到服务器返回的证书链消息后，本地完成证书链合法性校验
3. 服务器主动向客户端发送SSL alert number 40（即握手失败致命告警）
   整个过程虽然TCP连通，但TLS加密通道未建立，无法正常传输HTTPS业务数据。

从输出和debug报文分析，这类报错的常见触发原因包括：

• 未携带有效SNI（服务器名称指示）字段：根据debug输出，本次连接的ClientHello中SNI扩展长度仅4字节，未携带实际域名内容。如果服务端采用多虚拟主机共享端口部署规则，收到无有效SNI的连接请求会直接触发握手拒绝。
• 密码套件无匹配交集：服务端配置的允许密码套件范围，和客户端openssl上报支持的密码套件列表没有交集，服务器收到ClientHello后无法选出合规加密套件，直接返回握手失败告警。
• TLS协议版本不匹配：服务端强制禁用了SSLv3、TLS1.0、TLS1.1等老旧版本，但客户端默认协商的版本范围包含这些被禁用的版本，超出服务端允许边界就会被拦截。
• 双向TLS强制校验：服务端配置了客户端证书强制认证策略，但客户端在握手过程中未携带合法的客户端证书，服务器校验不通过即返回告警。
• TLS扩展不兼容：服务端要求的扩展能力（比如ALPN协议协商、特定签名算法要求、密钥交换策略）不在客户端支持的扩展范围内，字段不匹配就会触发握手失败。

• 优先补充有效SNI参数重跑连接测试，执行命令：
  openssl s_client -connect xxx.xxx.com:8773 -servername xxx.xxx.com
  替换为实际连接的域名，观察告警是否消失，这一步可解决绝大多数未携带SNI导致的握手拒绝问题。
• 对齐TLS版本范围测试：如果加完SNI仍报错，根据服务端支持的版本指定参数测试，比如指定TLS1.2版本执行：
  openssl s_client -connect xxx.xxx.com:8773 -servername xxx.xxx.com -tls1_2
  若服务端仅支持TLS1.3，可替换参数为-tls1_3，排除协议版本不匹配问题。
• 排查密码套件兼容性：先用openssl ciphers -v列出当前客户端支持的所有加密套件，和服务端配置的允许范围做比对，确认存在可协商的交集；测试时可手动指定匹配的套件，比如执行：
  openssl s_client -connect xxx.xxx.com:8773 -servername xxx.xxx.com -cipher ECDHE-RSA-AES128-GCM-SHA256
  若连通即代表是默认套件协商顺序、范围不匹配。
• 排查双向认证拦截：如果上述步骤均无效果，确认服务端是否开启了客户端证书强制校验，测试时通过-cert、-key参数传入对应的客户端证书与私钥，验证是否是双向TLS规则拦截。
• 深度定位字段差异：在openssl命令中增加-tlsextdebug -msg参数，逐段抓取握手报文字段，比对客户端、服务器上报的扩展、加密算法、版本字段的差异，精准定位具体拦截点。

内容的提问来源于stack exchange，提问作者user3236879