Minikube: Downloading kubelet: x509: certificate signed by unknown authority

Created on 17 Apr 2018  路  15Comments  路  Source: kubernetes/minikube

root@user01-VirtualBox:~# minikube start --vm-driver=kvm
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Downloading kubeadm v1.10.0
Downloading kubelet v1.10.0
E0417 15:28:25.329836 29194 start.go:234] Error updating cluster: downloading binaries: downloading kubelet: Error downloading kubelet v1.10.0: failed to download: failed to download to temp file: download failed: 5 error(s) occurred:

causfirewall-or-proxy ecertificate-errors kinbug
Source
picture Natarajan77

Most helpful comment

Well, it's not totally outside our control. I have the corporate CAs, I just need to know which truststore to append them to.

picture kevinpauli on 14 Jun 2019
👍2

All 15 comments

I get the same issue on MacOS but at the end of the url is : EOF

EmilianoCervantes picture EmilianoCervantes on 15 May 2018

I am seeing the same: E0531 07:13:56.412331 2648 start.go:234] Error updating cluster: starting kubelet:

ghost picture ghost on 31 May 2018

I got a similar but timeout error while starting the minikube:

root@user-VirtualBox:/home/user# sudo -E minikube start --vm-driver=none --bootstrapper=kubeadm
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Downloading kubeadm v1.10.0
Downloading kubelet v1.10.0
E0616 21:25:55.127459 11758 start.go:252] Error updating cluster: downloading binaries: downloading kubeadm: Error downloading kubeadm v1.10.0: failed to download: failed to download to temp file: download failed: 5 error(s) occurred:

  • Temporary download error: Get https://storage.googleapis.com/kubernetes-release/release/v1.10.0/bin/linux/amd64/kubeadm: dial tcp [2404:6800:4002:804::2010]:443: connect: network is unreachable
  • Temporary download error: Get https://storage.googleapis.com/kubernetes-release/release/v1.10.0/bin/linux/amd64/kubeadm: dial tcp: lookup storage.googleapis.com on 127.0.1.1:53: read udp 127.0.0.1:55690->127.0.1.1:53: i/o timeout
  • Temporary download error: Get https://storage.googleapis.com/kubernetes-release/release/v1.10.0/bin/linux/amd64/kubeadm: dial tcp [2404:6800:4002:804::2010]:443: connect: network is unreachable
  • Temporary download error: Get https://storage.googleapis.com/kubernetes-release/release/v1.10.0/bin/linux/amd64/kubeadm: dial tcp: lookup storage.googleapis.com on 127.0.1.1:53: read udp 127.0.0.1:49320->127.0.1.1:53: i/o timeout
  • Temporary download error: Get https://storage.googleapis.com/kubernetes-release/release/v1.10.0/bin/linux/amd64/kubeadm: dial tcp: lookup storage.googleapis.com on 127.0.1.1:53: read udp 127.0.0.1:45945->127.0.1.1:53: i/o timeout
aadhiyogi picture aadhiyogi on 16 Jun 2018

Hello, I also had a mistake to know. How should I solve it. Please help me to solve it
this is in the Centos7 System

[root@localhost bin]# minikube start
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Downloading Minikube ISO
153.08 MB / 153.08 MB [============================================] 100.00% 0s
Getting VM IP address...
Moving files into cluster...
Downloading kubeadm v1.10.0
Downloading kubelet v1.10.0
E0716 22:17:35.806802 1833 start.go:252] Error updating cluster: downloading binaries: downloading kubeadm: Error downloading kubeadm v1.10.0: failed to download: failed to download to temp file: download failed: 5 error(s) occurred:

KateJC picture KateJC on 16 Jul 2018

I'm having the same issues as the above.

kevin-s-wang picture kevin-s-wang on 16 Jul 2018

hello锛宖riends,I also meet this problem:Error updating cluster: downloading binaries: downloading kubeadm: Error downloading kubeadm v1.10.0: failed to download: failed to download to temp file: failed to copy contents: read: operation timed out

I stop minikube and restart minikube,this question does'n appear,you can also try this way.
@Natarajan77 @aadhiyogi @irdara

Dlgde picture Dlgde on 27 Jul 2018

it's also possible your inernet is not very good,please try many times

Dlgde picture Dlgde on 27 Jul 2018

@liqiang75 is right. I've tried a few times and finally it works.
You can repeat the following commands over and over again till it's successful. Though, personally, I don't think it's preferable but it works.

$ minikube delete 
$ rm -rf ~/.minikube
$ minikube start

However, I would suggest that the k8s team to put the artifacts onto a server(perhaps mirrors) that's also accessible for some particular countries.

kevin-s-wang picture kevin-s-wang on 28 Jul 2018
👍1

This sounds like a host or network misconfiguration. Do you mind sharing the output of:

 curl -iv  https://storage.googleapis.com

Thanks!

tstromberg picture tstromberg on 19 Sep 2018

curl -iv https://storage.googleapis.com

  • Rebuilt URL to: https://storage.googleapis.com/
  • Trying 172.217.11.176...
  • Connected to storage.googleapis.com (172.217.11.176) port 443 (#0)
  • found 148 certificates in /etc/ssl/certs/ca-certificates.crt
  • found 597 certificates in /etc/ssl/certs
  • ALPN, offering http/1.1
  • SSL connection using TLS1.2 / RSA_AES_256_GCM_SHA384
  • server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
  • Closing connection 0
    curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
    More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

RajeshBhojwani picture RajeshBhojwani on 25 Oct 2018

@RajeshBhojwani - I suspect that either the /etc/ssl/certs files on this system are too old for usage, or that there is a bad proxy which is intercepting and rewriting outgoing SSL certificates. Either way, if curl fails, there is a system misconfiguration that needs to be addressed.

One way to help debug the issue is to use:

echo | openssl s_client -connect storage.googleapis.com:443 \
  | egrep "^subject=|^issuer="

On my machine, I get the following output:

depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.storage.googleapis.com
verify return:1
DONE
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.storage.googleapis.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3

If you see a different list of issuers, something is intercepting your outgoing requests.

If you see the same list of issuers, I suspect you may need to update your locally installed certificates.

tstromberg picture tstromberg on 29 Oct 2018

We are also facing same issue, is there any work around present for this issue?

[root@minikube ~]# minikube start --vm-driver=none
Starting local Kubernetes v1.13.2 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Downloading kubeadm v1.13.2
Downloading kubelet v1.13.2
E0122 13:58:12.067076 26586 start.go:302] Error updating cluster: downloading binaries: downloading kubelet: Error downloading kubelet v1.13.2: failed to download: failed to download to temp file: download failed: 5 error(s) occurred:

witsriram2 picture witsriram2 on 22 Jan 2019

Closing because the issue of SSL interception is outside of our control. Mentioned the need to check for this condition in #3145 - thanks for the report!

tstromberg picture tstromberg on 24 Jan 2019

Well, it's not totally outside our control. I have the corporate CAs, I just need to know which truststore to append them to.

kevinpauli picture kevinpauli on 14 Jun 2019
👍2

@RajeshBhojwani - I suspect that either the /etc/ssl/certs files on this system are too old for usage, or that there is a bad proxy which is intercepting and rewriting outgoing SSL certificates. Either way, if curl fails, there is a system misconfiguration that needs to be addressed.

One way to help debug the issue is to use:

echo | openssl s_client -connect storage.googleapis.com:443 \
  | egrep "^subject=|^issuer="

On my machine, I get the following output:

depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.storage.googleapis.com
verify return:1
DONE
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.storage.googleapis.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3

If you see a different list of issuers, something is intercepting your outgoing requests.

If you see the same list of issuers, I suspect you may need to update your locally installed certificates.

I am having the same issue when trying to run

minikube start --vm-driver=none

When I run

echo | openssl s_client -connect storage.googleapis.com:443 \ | egrep "^subject=|^issuer="

I get almost the same output as you mentioned besides CN is now GTS CA 101

depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.storage.googleapis.com
verify return:1
DONE
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.storage.googleapis.com
issuer=/C=US/O=Google Trust Services/CN=GTS CA 1O1

Been having a lot of trouble trying to get Minikube up and running... tried just about everything I could think of. Any advice much appreciated

bmoe24x picture bmoe24x on 4 Feb 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

wudongyin picture wudongyin  路  3Comments
dkoston picture dkoston  路  3Comments
jroucheton picture jroucheton  路  3Comments
kphatak picture kphatak  路  3Comments
cherish3620 picture cherish3620  路  3Comments