HAProxy终止TLS时SNI unrecognized_name警告致Java 1.7客户端无法连接求助

你遇到的这个问题是Java 1.7的一个已知特性——它对SNI（Server Name Indication）的处理格外严格，当服务器返回unrecognized_name警告时会直接拒绝建立连接，而大多数现代客户端会忽略这个警告继续完成连接。结合你使用HAProxy和*.widgets.com通配符证书的环境，这里有几个可行的解决思路：

1. 确保HAProxy正确处理SNI请求，返回匹配的服务器名称 #

Java 1.7要求服务器在收到SNI请求后，必须返回与请求域名完全匹配的服务器标识，否则就会触发警告并断开连接。你需要调整HAProxy的SSL配置，确保它能正确识别客户端发送的SNI信息，并返回对应的证书关联域名。

示例HAProxy配置调整： #

在你的HTTPS前端配置块中，添加SNI匹配规则，确保所有.widgets.com相关的请求都能匹配到正确的证书和后端：

frontend https_frontend
    bind *:443 ssl crt /etc/haproxy/certs/wildcard_widgets_com.pem alpn h2,http/1.1
    # 匹配所有widgets.com子域名及根域名
    acl sni_widgets req.ssl_sni -m reg ^(.+\.)?widgets\.com$
    # 匹配到SNI后使用对应的后端
    use_backend widgets_backend if sni_widgets
    # 默认也指向同一后端，避免无SNI的请求出问题
    default_backend widgets_backend

这里的核心是req.ssl_sni ACL会捕捉客户端发送的SNI信息，确保HAProxy用正确的证书响应，从根源上避免返回unrecognized_name警告。

2. 检查通配符证书是否包含根域名widgets.com #

注意：标准的通配符证书*.widgets.com仅匹配所有子域名（如foo.widgets.com），不匹配根域名widgets.com。如果你的客户端有直接连接根域名的场景，HAProxy返回的证书会因为域名不匹配触发SNI警告，导致Java 1.7拒绝连接。

解决方法：

• 重新申请包含widgets.com和*.widgets.com的SAN（Subject Alternative Name）证书
• 在HAProxy中为根域名单独配置证书，通过多证书目录让HAProxy自动匹配：

  # 在bind指令中指定证书目录，HAProxy会根据SNI自动选择对应证书
  bind *:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1
  # 证书目录下存放两个文件：
  # widgets.com.pem（包含根域名证书）和 wildcard_widgets_com.pem（包含通配符证书）
  

3. 升级HAProxy到支持SNI的稳定版本 #

如果你的HAProxy版本较旧（比如1.6及以下），可能存在SNI处理的兼容性问题。建议升级到1.8+的稳定版本，新版本对SNI的支持更完善，能更好地适配Java 1.7这类对SNI要求严格的客户端。

4. 测试验证 #

调整配置后，你可以用openssl命令模拟Java 1.7的SNI请求，验证是否还存在unrecognized_name警告：

openssl s_client -connect your-haproxy-ip:443 -servername test.widgets.com

查看输出内容，如果没有出现unrecognized_name: test.widgets.com的提示，说明问题已经解决，Java 1.7客户端应该能正常建立连接了。

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