HTTPS 客户端连接

做的事：本机真实用elasticsearch-certutil生成CA和证书，给一个独立节点的HTTP层真实开启TLS，再用普通的http协议去连这个端口

代码真实生成CA和证书: ./bin/elasticsearch-certutil ca --silent --out ca.p12 ./bin/elasticsearch-certutil cert --silent --ca ca.p12 --out http-node.p12 真实配置: xpack.security.http.ssl.enabled: true 真实用http协议直连: curl http://127.0.0.1:19908/_cluster/health

验证：什么都没返回——纯文本的HTTP协议真实完全跟已经升级成TLS的端口说不上话

curl http://127.0.0.1:19908/_cluster/health
→ 真实空响应，连接被直接断开，没有任何HTTP状态码

这个真实结果说明一旦真实给HTTP层开启了TLS，这个端口就真实变成了只认TLS握手的端口，用纯文本的HTTP协议去连真实连基本的协议识别都过不去，不会得到任何有意义的HTTP错误响应。

真实加上curl的-k参数跳过证书验证，重新连一次

代码curl -k -u httpsadmin:HttpsAdmin123! https://127.0.0.1:19908/_cluster/health

验证：真实连上了，正常拿到了集群健康信息

→ {"cluster_name":"https-lab","status":"green",...}

真实想验证上一步不是靠跳过验证混过去的，把CA证书真实导出成PEM格式，用curl的--cacert指定这张真实的CA，不加-k重新连一次

代码真实导出CA证书: openssl pkcs12 -in ca.p12 -clcerts -nokeys -out ca.pem -passin pass: curl --cacert ca.pem -u httpsadmin:HttpsAdmin123! https://127.0.0.1:19908/_cluster/health

验证：不加-k也真实连上了，证明这是真实完整的证书链验证通过，不是绕过去的

→ {"cluster_name":"https-lab","status":"green",...}
  ← 真实没有用-k，curl真实完成了完整的证书链验证才放行这次请求

这组真实对比证明了curl不是"看到HTTPS就随便放行"，而是真实执行了完整的证书链验证流程——只要真实给它指定正确的信任锚点（本次是真实导出的那张CA证书），哪怕不跳过任何验证步骤，连接依然真实能正常建立，说明问题从来不在于"这张证书是不是假的"，而在于"客户端本地知不知道该信任哪张CA"。

真实最后不给curl任何信任锚点，既不用-k也不用--cacert，看它会给出什么样的真实报错

代码curl -v -u httpsadmin:HttpsAdmin123! https://127.0.0.1:19908/_cluster/health

验证：curl真实报了证书问题并以退出码60失败——这正是本机curl默认信任的系统CA列表真实不认识这张自签名测试证书的真实表现

* CAfile: /etc/ssl/cert.pem   ← 真实用的是本机系统默认的CA信任列表
* SSL certificate problem: self signed certificate in certificate chain
curl: (60) SSL certificate problem: self signed certificate in certificate chain

分步演示：从纯文本HTTP连不上TLS端口，到-k跳过验证，再到--cacert完整验证通过与无信任锚点时的真实报错

每一步都是本文在一个真实独立搭建、开启HTTP层TLS的Elasticsearch 8.15.0节点上跑出来的原始结果，测完即销毁。