apiserver报http: TLS handshake error from 10.4.7.11:56612: remote error: tls: bad certificate

最新推荐文章于 2025-07-12 09:53:00 发布
原创 最新推荐文章于 2025-07-12 09:53:00 发布 · 6.2k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#k8s

遇到CoreDNS无法启动的问题，原因是kube-apiserver的TLS配置错误，导致http: TLSHandshakeError。修复apiserver配置后，问题得到解决，但具体原因未明。

起初使发现coredns一直启动不起来，查看报错， http: TLS handshake error from 10.4.7.11:56612: remote error: tls: bad certificate修改kube-apiserver 配置

导致

修改过来重启apiserver，问题解决，原因未知。

 

 

happyqiangsir
关注
解决TLS握手失败：从错误分析到成功连接
探索云原生与智能化驱动下的安全运维新范式。关注DevSecOps、可观测性、AIOps等前沿领域，与您共赴技术前沿。
09-03 2473
在物联网和网络应用开发中，安全通信至关重要。TLS（传输层安全协议）是保障数据传输安全的关键技术，但有时我们可能会遇到TLS握手失败的问题。本文将通过一个实际案例，详细讲解如何分析TLS握手错误并成功解决问题。
【Docker】完美解决拉取镜像超时报错：ERROR: Get https://registry-1.docker.io/v2/
热门推荐
liu_chen_yang的博客
02-20 12万+
因为我们下载的镜像是外网的镜像资源，所以下载的速度会非常的慢，甚至大概率下载时会报错，所以需要我们配置一个国内的服务器镜像地址，国内服务器镜像地址有很多，这里咱们就说一下阿里镜像加速器的配置方法。
http: TLS handshake error from xxx.xxx.xxx.xxx:xxxx : read tcp xxx.xxx.xxx.xxx:6443-＞xxx.xxx.xxx.xxx
06-16 2610
使用阿里云SLB做 kube-apiserver负载，查看kube-apiserver 日志一直在报 TLS handshake error
AWS EKS 相关错误修复 - remote error: tls: internal error - CSR pending
Kainx
12-13 879
AWS EKS 相关错误修复 - remote error: tls: internal error - CSR pending
idea集成docker,并使用windows 下 的docker推送镜像到harbor
Street_Walker的博客
12-02 1634
1.登录Harbor地址 然后选择项目->打开自己的项目 此处使用的上图右下角的提示命令进行推送镜像.(图中A/B是Harbor中的仓库名称) 2.推送数据实际使用的命令是 docker push [REPOSITORY]:[TAG] 举例:对应的推送命令是:docker push A/B:7(此处本地仓库要和Harbor仓库的仓库名一致) 3.推送报错:remote error: tls: internal error 网友提示:在配置文件中添加仓库地址,此处是推送镜像不是下载镜像,几乎没什么
三种方法解决http: TLS handshake error from [::1]:51325: remote error: tls: unknown certificate
weixin_64123373的博客
08-17 9959
解决http: TLS handshake error
解决：http: TLS handshake error from *
liuzhen007的专栏
11-13 1万+
目录 问题 解决 结尾 问题 今天以容器的形式在公网上一个部署了一个云服务，在测试环境是没有问题的，不知道为什么部署到 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 handshak
docker: Error response from daemon: ... : net/http: TLS handshake timeout.
K8sCat
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...
Fabric测试智能合约BUG：Server TLS handshake failed in 13...LS handshake server=Orderer remoteaddres...
lxd_max的博客
07-16 1048
Fabric部署智能合约BUG：error getting endorser client for install: endorser client failed to connect ...
Docker : Error response from daemon: Get https://docker.elastic.co/v2/: net/http: TLS handshake time
九师兄
07-04 3176
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
Error response from daemon: Get https://harbor.od.com/v2/: dial tcp 10.4.7.200:443: connect: connect
Laiyunpeng666的博客
06-18 4426
创建私有镜像仓库后远程的主机登录不上去保报错如下 [root@hdss7-22 ~]# docker login harbor.od.com Username: admin Password: Error response from daemon: Get https://harbor.od.com/v2/: dial tcp 10.4.7.200:443: connect: connection refused 然而我是在200上创建的私有仓库，通过映射的端口为180—》80 [root@hdss7-20
HTTPS 发送请求出现TLS握手失败
阿信今天的代码没bug的博客
07-07 1925
我本人对这个方面的研究不深，到达了我的知识盲区，刚好身边有个博士做过这方面的研究，他所在的团队实现了TLS1.3的一个版本，对这个非常熟悉，请他看了一下日志，可以判断，也是缺少椭圆曲线；两者对比可以发现，服务端选择了TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384加密套件，正常请求是有这个套件的，而失败的请求是没有这个套件的；经过了一天的努力，终于发现了问题所在，之前有个哥们不知道因为什么原因，把SUN公司的ECC曲线都删掉了，导致了问题；从网上找了写方法，都没有解决；
TLS handshake error : : tls: bad certificate
bianmu3488的博客
08-02 5766
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: bad certificate
吴派三叔的博客
04-07 8630
2020/04/07 16:35:53 http: TLS handshake error from 127.0.0.1:61171: remote error: tls: bad certificate 用以下命令生成 tls openssl genrsa -out server.key 2048 openssl ecparam -genkey -name secp384r1 -out serv...
https自签证书tls握手时错误或go系统错误处理
weixin_46078854的博客
11-12 9466
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 :=
remote error: tls: bad certificate
最新发布
喝醉酒的小白
07-12 779
这些修改应该能解决 “bad certificate” 错误，确保 etcd 节点间的 TLS 通信正常工作。根据提供的 etcd 日志，存在 TLS 证书问题导致连接被拒绝。表明客户端证书未被 etcd 服务器接受。对于 peer 证书，应该显示。
记一次 etcd 报错 error “remote error: tls: bad certificate“, ServerName ““)
ming12353的博客
07-23 5520
解决：etcd证书请求文件中增加hosts参数将etcd节点加入后重新生成证书文件。
ngrok 1.7搭建报错remote error: tls: bad certificate
竹生的专栏
11-13 4965
ngrok 1.7搭建报错 最近重新搭建了一遍ngrok的服务器，参考：https://zhuanlan.zhihu.com/p/33794707 由于ngrok v1版本很久都没有维护了，编译完成后，启动时服务端遇到了错误：remote error: tls: bad certificate 在网上搜索了半天，有人说是golang版本的问题，将golang版本从1.17降低到1.9后，仍然没有解决。偶然间发现客户端上的日志提示x509: certificate is valid for xxx, not
frp 内网穿透突然提示remote error: tls: unknown certificate，
leo的博客
08-24 1101
因为开发小程序，需要搭建内外测试环境，于是安装了frp内网穿透软件，经过手搓各种配置，终于网通了，但使用了一段时间，突然访问不了了。经过多方排查，根据提示应该问题处在证书上，在本机客户端里面有两个证书，是域名申请的证书，会不会是域名证书问题，此时我重新下载证书。日志提示remote error: tls: unknown certificate。替换掉之前放置的证书，看配置文件。页面端提示连接不是私密连接。没有问题，重启一下服务。
使用gin，http: TLS handshake error from 192.168.149.79:54957: remote error: tls: unknown certificate
05-23
### Gin框架中TLS握手错误（unknown certificate）解决方案 在Gin框架中，当出现`unknown certificate`的TLS握手错误时，通常是因为服务器端使用的SSL/TLS证书未被客户端信任。以下是可能的原因以及对应的解决方法： #### 1. **Nginx代理引起的双重HTTPS配置** 如果应用运行在一个通过Nginx反向代理的服务架构下，并且Nginx和后端服务都启用了独立的HTTPS协议，则可能导致双层证书冲突。这种情况下，建议统一管理证书并调整Nginx配置[^1]。 - 确保Nginx作为唯一的HTTPS终止点。 - 配置Nginx以将HTTP请求转发到后端Gin服务，而不重新加密流量： ```nginx server { listen 443 ssl; server_name example.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { proxy_pass http://localhost:8080; # 后端Gin服务地址 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } ``` #### 2. **自签名证书的信任问题** 如果使用的是自签名证书而非权威机构颁发的证书，则需要手动让客户端信任该证书。这可以通过以下方式实现[^2]： - 在浏览器或操作系统级别导入根CA证书。 - 如果是Go程序调用API接口，可以加载自定义证书池： ```go package main import ( "crypto/tls" "crypto/x509" "io/ioutil" "net/http" ) func main() { certPool := x509.NewCertPool() pemData, _ := ioutil.ReadFile("/path/to/ca-cert.pem") certPool.AppendCertsFromPEM(pemData) client := &http.Client{ Transport: &http.Transport{ TLSClientConfig: &tls.Config{RootCAs: certPool}, }, } resp, err := client.Get("https://example.com/") if err != nil { panic(err) } defer resp.Body.Close() body, _ := ioutil.ReadAll(resp.Body) println(string(body)) } ``` #### 3. **禁用特定加密算法** 有时老旧或不兼容的加密算法也会引发握手失败。可以在初始化Gin路由时指定支持的安全加密套件列表，从而排除潜在风险[^3]。 ```go package main import ( "fmt" "github.com/gin-gonic/gin" "net/http" "crypto/tls" ) func main() { r := gin.Default() tlsConf := &tls.Config{ MinVersion: tls.VersionTLS12, PreferServerCipherSuites: true, CipherSuites: []uint16{ tls.TLS_AES_128_GCM_SHA256, tls.TLS_CHACHA20_POLY1305_SHA256, tls.TLS_AES_256_GCM_SHA384, }, } srv := &http.Server{ Addr: ":443", Handler: r, TLSConfig: tlsConf, } fmt.Println("Serving HTTPS on :443...") if err := srv.ListenAndServeTLS("/path/to/server.crt", "/path/to/server.key"); err != nil { panic(err) } } ``` #### 4. **网络超时或其他异常情况** 对于因网络延迟等原因造成的TLS握手超时问题，可适当增加连接等待时间或者排查DNS解析、防火墙策略等方面是否存在阻碍[^4]。 --- ### 总结 以上提供了针对不同场景下的几种常见解决办法。实际操作过程中需结合具体情况分析根本原因再采取相应措施。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值