解决：http: TLS handshake error from *

最新推荐文章于 2024-10-12 18:28:21 发布
最新推荐文章于 2024-10-12 18:28:21 发布
阅读量1.8w 收藏 4
点赞数 3
CC 4.0 BY-SA版权
分类专栏： 服务器 文章标签： http 网络协议 网络
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/liuzehn/article/details/121302736
博主分享了在将云服务从测试环境部署到beta环境时遇到的TLS握手失败问题，通过分析发现是由于两层HTTPS证书不一致。解决办法包括统一证书或仅用一层，强调了在开发中考虑生产环境部署问题的重要性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

目录

  • 问题
  • 解决
  • 结尾

问题

今天以容器的形式在公网上一个部署了一个云服务，在测试环境是没有问题的，不知道为什么部署到 beta 环境就出现了问题，导致 https 协议文件访问失败。

具体报错信息如下：

2021/11/09 07:15:58 http: TLS handshake error from 125.64.94.138:34428: remote error: tls: bad certificate\
2021/11/09 07:15:58 http: TLS handshake error from 125.64.94.138:36510: EOF\
2021/11/09 07:15:58 http: TLS handshake error from 125.64.94.138:39042: read tcp 172.17.0.79:9443->125.64.94.138:39042: read: connection reset by peer\
2021/11/09 07:15:58 http: TLS handshake error from 125.64.94.138:41490: EOF\
2021/11/09 07:15:58 http: TLS handshake error from 125.64.94.138:42006: read tcp 172.17.0.79:9443->125.64.94.138:42006: read: connection reset by peer\
2021/11/09 07:16:00 http: TLS handshake error from 125.64.94.138:42738: read tcp 172.17.0.79:9443->125.64.94.138:42738: read: connection reset by peer\
2021/11/09 07:16:01 http: TLS handshake error from 125.64.94.138:51154: read tcp 172.17.0.79:9443->125.64.94.138:51154: read: connection reset by peer\
2021/11/09 07:16:01 http: TLS handshake error from 125.64.94.138:33806: read tcp 172.17.0.79:9443->125.64.94.138:33806: read: connection reset by peer\
2021/11/09 07:16:01 http: TLS handshake error from 125.64.94.138:34836: read tcp 172.17.0.79:9443->125.64.94.138:34836: read: connection reset by peer\
2021/11/09 07:16:01 http: TLS handshake error from 125.64.94.138:35318: read tcp 172.17.0.79:9443->125.64.94.138:35318: read: connection reset by peer\
2021/11/09 07:16:16 http: TLS handshake error from 125.64.94.138:34338: read tcp 172.17.0.79:9443->125.64.94.138:34338: read: connection reset by peer\
2021/11/09 11:24:42 http: TLS handshake error from 209.17.97.114:65306: EOF\
2021/11/09 13:46:06 http: TLS handshake error from 89.248.174.193:39762: EOF\
2021/11/09 15:51:50 http: TLS handshake error from 165.227.163.245:38494: EOF

通过报错信息，大致猜测可能是证书原因导致的握手失败，具体原因还不是很清楚，至少是一个分析和思考的方向。

进一步分析报错日志，可以发现握手过程中，IP 地址为 125.64.94.138 的机器不断尝试切换其他端口，但是每次都被重置连接，最终导致连接失败。

解决

网上搜索了很多资料，但是介绍的方法都没有解决自己遇到的问题，后来在梳理整体流程的时候发现了原因。因为容器服务本身同时支持 http 协议和 https 协议，有一层 https 证书，在测试环境中没有问题，但是 beta 环境中所有服务访问的入口都要经过 Nginx 代理服务转发请求，而 Nginx 服务本身又设置了一层 https 证书，二层证书不一致导致了错误的发生。

因此，解决方法有两种，一是仅使用一层 https 证书；二是统一两层证书，使用相同的签名证书。

结尾

有时候，很多问题在自测的时候很难发现，是因为没有放到具体的生产环境中去，因此，开发过程中一定要考虑到未来部署后可能出现的问题，编码时尽量规避。

作者简介：大家好，我是 liuzhen007（Data-Mining），是一位音视频技术爱好者，同时也是CSDN博客专家、华为云社区云享专家、签约作者，欢迎关注我分享更多干货！

解决TLS握手失败：从错误分析到成功连接
TechEnthusiast的博客
09-03 1759
在物联网和网络应用开发中，安全通信至关重要。TLS（传输层安全协议）是保障数据传输安全的关键技术，但有时我们可能会遇到TLS握手失败的问题。本文将通过一个实际案例，详细讲解如何分析TLS握手错误并成功解决问题。
Docker : Error response from daemon: Get https://docker.elastic.co/v2/: net/http: TLS handshake time
九师兄
07-04 3120
1.美图 2.概述 (base) lcc@lcc ~$ docker pull docker.elastic.co/elasticsearch/elasticsearch:6.3.2 Error response from daemon: Get https://docker.elastic.co/v2/: net/http: TLS handshake timeout
http: TLS handshake error from xxx.xxx.xxx.xxx:xxxx : read tcp xxx.xxx.xxx.xxx:6443-＞xxx.xxx.xxx.xxx
06-16 2540
使用阿里云SLB做 kube-apiserver负载，查看kube-apiserver 日志一直在报 TLS handshake error
三种方法解决http: TLS handshake error from [::1]:51325: remote error: tls: unknown certificate
weixin_64123373的博客
08-17 8981
解决http: TLS handshake error
apiserver报http: TLS handshake error from 10.4.7.11:56612: remote error: tls: bad certificate
strideahead的博客
04-05 6190
起初使发现coredns一直启动不起来，查看报错， http: TLS handshake error from 10.4.7.11:56612: remote error: tls: bad certificate修改kube-apiserver 配置 导致 修改过来重启apiserver，问题解决，原因未知。
HTTPS 发送请求出现TLS握手失败
阿信今天的代码没bug的博客
07-07 1611
我本人对这个方面的研究不深，到达了我的知识盲区，刚好身边有个博士做过这方面的研究，他所在的团队实现了TLS1.3的一个版本，对这个非常熟悉，请他看了一下日志，可以判断，也是缺少椭圆曲线；两者对比可以发现，服务端选择了TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384加密套件，正常请求是有这个套件的，而失败的请求是没有这个套件的；经过了一天的努力，终于发现了问题所在，之前有个哥们不知道因为什么原因，把SUN公司的ECC曲线都删掉了，导致了问题；从网上找了写方法，都没有解决；
https自签证书tls握手时错误或go系统错误处理
weixin_46078854的博客
11-12 9332
https自签证书tls握手时报错：2021/11/03 09:22:53 http: TLS handshake error from ip:port: remote error: tls: unknown certificate， 这属于go包系统级别的错误，不可捕获和忽略，只能用方法3来减少错误日志文件大小。 1.浏览器添加客户端证书和CA根证书； 2.系统级别的崩溃信息:syscall.Dup2 eg: fatal error: runtime: out of memory 代码： f, e :=
Error response from daemon: Get https:// TLS handshake timeout
麦迪康
08-20 765
Error response from daemon: Get https://10.239.45.10/v2/: net/http: TLS handshake timeout 配置私有docker 仓库timeout问题 1.确认添加私有仓库成功 2.确认配置docker proxy vim /etc/default/docker export http_proxy="http://" export https_proxy="https://" DOCKER_OPTS='-H tcp://0.0.0.
docker: Error response from daemon: ... : net/http: TLS handshake timeout.
架构大师笔记
01-23 1万+
使用国内的镜像加速器: Docker 中国官方镜像加速 阿里云镜像加速 例如： sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://registry.docker-cn.com"] } EOF sudo systemctl daemon...
解决报错Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: TLS handshaketimeout
ZL_do_it的博客
09-08 2658
解决报错Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: TLS handshaketimeout 解决docker拉取镜像时的报错： [root@zlhost docker-file]# docker pull java-8 Using default tag: latest Error response from daemon: Get https://registry-1.docker.io/v2/l
部署dashboard
weixin_45444133的博客
05-04 1329
1.部署dashboard mkdir -p /home/yaml/dashboard && cd /home/yaml/dashboard wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml #默认Dashboard只能集群内部访问，修改Service为NodePort类型，暴露到外部： vi recommended.yaml ... ki
istio多节点时报错TLS handshake error x.x.x.x: EOF或者 code = Canceled desc = context canceled
weixin_42411864的博客
05-11 921
修改每个节点网卡的mtu 给到8000！这问题卡我快两个月了终于在昨天翻阅stackoverflow的时候看到又人无意间提了一嘴，试了一下就好了，所有有时候不是 软件的问题，不是集群的问题，是最底层的网络问题，这边总结一下思路一般报错EOF的都是请求的时候东西太大或者连接失效从而截断了，之前写上传文件的时候也遇到过！
SSL/TLS的Handshake过程与javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure异常
热门推荐
成长的足迹
01-24 5万+
一.SSL/TLS的Handshake过程 在SSL/TLS的Handshake过程中，客户端与服务器之间需要交换参数，具体过程如下： 客户端提供其所支持的各种cipher suites（包含加密算法和Hash函数） 服务器从中选择自己也支持的cipher suite，并通知客户端，表明两者将以此进行数据传输 服务器同时将自己的数字证书（包括服务器名称、CA和公钥）作为标识符发给客户端 ...
master节点TLS握手协议报错问题实例处理
hedao0515的专栏
03-19 7343
master节点TLS握手协议报错问题实例处理
TLS handshake error : : tls: bad certificate
bianmu3488的博客
08-02 5737
Aug 02 10:55:52 k8stian-m2 kube-apiserver[6001]: I0802 10:55:52.563367 6001 controller.go:105] OpenAPI AggregationController: Processing item k8s_internal_local_delegation_chain_0000000001Aug 02 10...
TLS协商报错Handshake failure问题解决
qq_42288975的博客
10-12 3400
介绍了curl工具协助定位tls连接问题，tcp连接报错Handshake failure可能原因是协商的加密套件存在问题导致。
Hyperledger Fabric报错TLS handshake failed with error EOF server=PeerServer remoteaddress=
weixin_39304739的博客
02-21 5786
在做超级账本的例子时，用java实现第一个小例子Fabcar。但是在安装调用链码时报错了。然后我运行Fabcar的例子时，用Go可以，用java不行。还没有找到解决方案T——T （1）先决条件：因为我实现第一个网络的例子时，./byfn.sh up是可以正确调用go版本的abstore，所以我认为先决条件是对的。在这里再贴一下： Ubuntu18.04 go：go version go...
如何修复SSL/TLS握手失败
yuyan_jia的博客
08-24 1万+
https://segmentfault.com/a/1190000021559557 此文主要内容翻译至博客How to Fix the SSL/TLS Handshake Failed Error?,并做了一些添加,修改和删除. 当浏览器向web服务器(如Apache)发送一个安全的请求时,ssl/tls握手过程就开始了.ssl/tls错误时有发生,其中最常见的错误就是SSL Handshake Failed error.下面我们就来讲解什么是SSL/TLS握手失败,以及如何解决. SSL/TLS
net/http: TLS handshake timeout
wangyhwyh753的博客
04-14 6258
该错误表明http连接超时，这是因为docker默认使用的引擎无法下载国外的镜像源。通过配置/etc/docker/daemon.json为国内的加速引擎可以解决这个问题。 { "registry-mirrors": ["https://registry.docker-cn.com"] } systemctl reload-daemon重新加载配置，利用systemctl rest...
[default] Error sending telemetry FetchError: Client network socket disconnected before secure TLS connection was established
最新发布
03-08
<think>好的，我现在要解决用户遇到的“FetchError: 客户端网络套接字在安全TLS连接建立之前断开”的问题。首先，我需要理解这个错误的具体原因。根据错误信息，看起来是在尝试建立TLS连接之前，客户端的网络套接字就已经断开了。可能的原因有很多，比如网络不稳定、服务器配置问题、客户端超时设置不当，或者是证书问题等等。 根据用户提供的引用内容，引用[1]提到了资源清理、错误处理和测试的重要性，引用[2]涉及TLS的数据完整性，引用[3]提到了设备厂商的安全方案。这些可能都与问题相关。我需要综合这些信息来提出解决方案。 首先，检查网络连接稳定性。用户可能在发送遥测数据时遇到网络波动，导致连接在TLS握手完成前断开。需要建议用户检查网络状态，使用重试机制，并增加超时时间。比如，在代码中设置合理的连接超时和读写超时，避免因短暂的网络问题导致连接中断。 其次，TLS握手失败可能由证书问题引起。服务器证书是否有效、是否被客户端信任、是否过期，这些都需要检查。引用[2]提到SSL/TLS使用散列算法确保数据完整性，所以证书的有效性至关重要。用户应该验证证书链，必要时在开发环境中暂时禁用证书验证（但生产环境不推荐）。 然后，服务器端配置也需要检查。TLS版本和密码套件的兼容性可能导致握手失败。确保服务器支持现代协议如TLS 1.2或1.3，并配置合适的密码套件。引用[1]中的测试建议，用户应在不同网络条件下测试协议实现，这可能包括调整服务器配置后的测试。 客户端重连逻辑也是关键。引用[1]提到资源清理和错误处理，客户端在连接断开后应正确关闭传输并尝试重新连接。实现指数退避策略，避免频繁重连加重服务器负担。 此外，客户端和服务器日志可以提供更多线索。检查服务器日志是否有TLS握手失败的记录，客户端日志是否有更详细的错误信息。引用[3]提到设备厂商的安全方案，可能涉及身份识别，所以也需要检查客户端认证是否正确，比如客户端证书是否有效。 防火墙或代理的问题也不容忽视。有些网络中间件可能会干扰TLS连接，特别是在企业环境中。用户需要确保防火墙允许TLS端口（如443）的通信，并且代理配置正确。 最后，更新依赖库和操作系统。旧的SSL/TLS库可能存在兼容性问题，更新到最新版本可以修复已知的bug或支持新的协议版本。 总结以上思路，解决方案应包括网络稳定性检查、超时设置、证书验证、服务器配置调整、重连机制、日志分析、防火墙检查以及依赖更新等方面。同时，用户应参考引用中的建议，如实施全面的错误处理和充分测试，以确保解决方案的可靠性。</think>针对客户端网络套接字在TLS连接建立前断开的问题，请按以下步骤排查和解决： ### 一、检查网络连接稳定性 1. 验证客户端到服务器的网络可达性 - 使用$ping$或$traceroute$命令测试基础网络连通性 - 检查是否存在间歇性丢包现象（建议持续监控5分钟以上） 2. 增加连接超时设置 ```python # Python示例：设置超时为10秒 import requests response = requests.post(url, data=telemetry, timeout=(3.05, 10)) ``` ### 二、处理TLS握手问题 1. 验证证书链完整性 - 确保服务器证书包含完整的中间证书链 - 使用OpenSSL检测：$$openssl s_client -connect your_server:443 -showcerts$$ 2. 检查协议版本兼容性 - 禁用不安全的TLS版本（如SSLv3），强制使用TLS 1.2+ - Python强制TLS版本示例： ```python import ssl context = ssl.create_default_context() context.options |= ssl.OP_NO_SSLv3 | ssl.OP_NO_SSLv2 | ssl.OP_NO_TLSv1 | ssl.OP_NO_TLSv1_1 ``` ### 三、实现可靠的重连机制 1. 指数退避重试算法 ```python import time from requests.exceptions import ConnectionError retries = 3 backoff_factor = 0.5 for attempt in range(retries): try: response = requests.post(url, data=telemetry) break except ConnectionError: if attempt == retries - 1: raise delay = backoff_factor * (2 ** attempt) time.sleep(delay) ``` ### 四、服务器端配置优化 1. 调整keepalive参数（以Nginx为例）： ``` http { keepalive_timeout 75s; keepalive_requests 100; } ``` 2. 检查TCP快速打开配置： ``` # sysctl -w net.ipv4.tcp_fastopen=3 ``` ### 五、诊断工具使用 1. Wireshark抓包分析： - 过滤条件：$$tcp.port == 443 && (ssl.handshake || tcp.analysis.retransmission)$$ 2. 客户端调试模式： ```python import http.client http.client.HTTPConnection.debuglevel = 1 ``` ### 六、进阶检查项 1. 验证MTU大小是否合适： - 使用$ping -s 1472 your_server$测试分包情况 - 确保没有因TCP分段导致握手失败 2. 检查TCP窗口缩放配置： ``` # sysctl -w net.ipv4.tcp_window_scaling=1 ``` [^1]: 资源清理和错误处理建议来自基础网络通信规范 [^2]: TLS完整性验证方法参考加密通信最佳实践 [^3]: 设备认证要求符合物联网安全方案标准
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Data-Mining

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值