Certificate is valid for ... not ....

[dweidenfeld]

Hi there,

I have an issue with the nginx example. My hoster is contabo.de/com. I've setup Kubernetes by kubeadm.

time="2017-07-17T15:40:27Z" level=error msg="Error while processing certificate requests: Get https://acme-v01.api.letsencrypt.org/directory: x509: certificate is valid for contabo.at, contabo.ch, contabo.org, contaboch.contabo.at, contaboorg.contabo.at, cpanel.contabo.at, cpanel.contabo.ch, cpanel.contabo.org, mail.contabo.at, mail.contabo.ch, mail.contabo.org, webdisk.contabo.at, webdisk.contabo.ch, webdisk.contabo.org, webmail.contabo.at, webmail.contabo.ch, webmail.contabo.org, www.contabo.at, www.contabo.ch, www.contabo.org, www.contaboch.contabo.at, www.contaboorg.contabo.at, not acme-v01.api.letsencrypt.org" context=kubelego

I think the problem is not directly with kube-lego, but with Kubernetes itself, but I don't know how to fix it, or what it means.

Thanks

[VasekPurchart]

I have run into this isssue as well, deployed on a kubeadm initalized cluster too.

From my reading and poking around I think the problem might lie in kube-lego after all. At first I thought this could be related to redirection http -> https somehow (HSTS somewhere or the ingress default redirections).

But I think the problem occurs earlier in the process, the error message comes from: https://github.com/jetstack/kube-lego/blob/784fc8fef5703665bd5f20ff65922ee038e09a95/pkg/kubelego/configure.go#L109 (I think, never done anything in Go :) ) which from the method name and comment looks like its part of validating if existing cert is still valid? And kubeadm (or something else in Kubernetes) sets up a self signed cert (in my case just for ingress.local) to allow access with https. I can confirm this is working through browser (with a warning about the self-signed cert).

So is it possible that when trying to read the validity of current certs, the self-signed cert is read and (maybe the underlying lib) throws an error about it not being "valid"?

@munnerz could you please check this theory? I think this is loosely relevant to the "reachability" discussion here #173.

[VasekPurchart]

@dweidenfeld have please found a workaround/solution that you could share? What were your next steps?

[VasekPurchart]

Found now also #149, but the error there was different, my guess is that that was in the real authorization phase, since the message contains authorization failed, but in this case does not.

Also as I mentioned I too thought this would be HSTS related (which was the resolution of that issue), but from my localhost (which has no VPN to the cluster or something like that yet) I see only:

$ curl -v http://hello.favi.tech/.well-known/acme-challenge/_selftest
*   Trying 185.175.84.224...
* Connected to hello.favi.tech (185.175.84.224) port 80 (#0)
> GET /.well-known/acme-challenge/_selftest HTTP/1.1
> Host: hello.favi.tech
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.13.5
< Date: Tue, 10 Oct 2017 17:36:48 GMT
< Content-Type: text/plain
< Content-Length: 16
< Connection: keep-alive
< 
* Connection #0 to host hello.favi.tech left intact
BRXVvGagIimiyFoP

(Also you can see, that the response is working, which I forgot to mention before).

And with the testing I did before I even set up the nginx controller with:

• ssl-redirect: 'false'
• hsts: 'false'

Also I can see now, that the self-signed certificate actually comes from here: https://github.com/kubernetes/ingress-nginx#default-ssl-certificate.

[dweidenfeld]

My workaround is using traefik. It works flawlessly out of the box.

[VasekPurchart]

@dweidenfeld thanks for the tip, will have a look at it.

[VasekPurchart]

I have finally solved the issue for me, in the end this was not kube-lego related, although I believe better debug info might have pointed me in the right direction sooner. I stumbled upon the same behavior later when setting up a different part of the infrastructure.

My issue was caused by kube-dns in combination with wildcard DNS entry pointing to the cluster plus hostname, which was resolvable to this address. This resulted in LE's domains (or any other 2nd lvl domain) to be resolved back to the cluster, where the self-signed cert was served.