Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Downloading kubelet: x509: certificate signed by unknown authority #2739

Closed
Natarajan77 opened this issue Apr 17, 2018 · 15 comments
Closed

Downloading kubelet: x509: certificate signed by unknown authority #2739

Natarajan77 opened this issue Apr 17, 2018 · 15 comments
Labels
cause/firewall-or-proxy When firewalls or proxies seem to be interfering ev/certificate-errors failed due to certificate issues kind/bug Categorizes issue or PR as related to a bug.

Comments

@Natarajan77
Copy link

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:
@EmilianoCervantes
Copy link

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

@ghost
Copy link

ghost commented May 31, 2018

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

@aadhiyogi
Copy link

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:

@KateJC
Copy link

KateJC commented Jul 16, 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:

@kevin-s-wang
Copy link

I'm having the same issues as the above.

@Dlgde
Copy link

Dlgde commented Jul 27, 2018

hello，friends,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
Copy link

Dlgde commented Jul 27, 2018

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

@kevin-s-wang
Copy link

@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.

@tstromberg tstromberg changed the title while trying to start it throws this error on ubuntu "certificate signed by unknown authority" Downloading kubelet: x509: certificate signed by unknown authority Sep 19, 2018
@tstromberg
Copy link
Contributor

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

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

Thanks!

@tstromberg tstromberg added failed/local-networking startup failures due to networking issues kind/bug Categorizes issue or PR as related to a bug. driver/kvm ev/certificate-errors failed due to certificate issues cause/poor-internet Failed due to internet access issues os/linux and removed failed/local-networking startup failures due to networking issues labels Sep 19, 2018
@RajeshBhojwani
Copy link

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.

@tstromberg
Copy link
Contributor

tstromberg commented Oct 29, 2018 •
edited
Loading

@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.

@witsriram2
Copy link

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:

@tstromberg tstromberg added cause/firewall-or-proxy When firewalls or proxies seem to be interfering and removed cause/poor-internet Failed due to internet access issues co/kvm os/linux labels Jan 24, 2019
@tstromberg
Copy link
Contributor

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 tstromberg mentioned this issue Feb 6, 2019
Closed
@kevinpauli
Copy link

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

@bmoe24x
Copy link

bmoe24x commented Feb 4, 2020

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
cause/firewall-or-proxy When firewalls or proxies seem to be interfering ev/certificate-errors failed due to certificate issues kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests