jetstack
Cannot validate domain (possibly because it is pure IPv6)
Log entry (with domain and IP changed)
2016-12-20T15:11:35.539614335Z time="2016-12-20T15:11:35Z" level=info msg="process certificates requests for ingresses" context=kubelego
2016-12-20T15:11:35.540744315Z time="2016-12-20T15:11:35Z" level=info msg="creating new secret" context=secret name=echomap-tls namespace=default
2016-12-20T15:11:35.540765345Z time="2016-12-20T15:11:35Z" level=info msg="no cert associated with ingress" context="ingress_tls" name=echomap namespace=default
2016-12-20T15:11:35.540782762Z time="2016-12-20T15:11:35Z" level=info msg="requesting certificate for foo.example.com,bar.example.com" context="ingress_tls" name=echomap namespace=default
2016-12-20T15:12:49.697426907Z time="2016-12-20T15:12:49Z" level=warning msg="authorization failed after 1m0s: reachabily test failed: Get http://bar.example.com/.well-known/acme-challenge/_selftest: dial tcp [here:goes:my:correct:ipv6:address]:80: connect: network is unreachable" context=acme domain=bar.example.com
2016-12-20T15:12:56.120965529Z time="2016-12-20T15:12:56Z" level=warning msg="authorization failed after 1m0s: reachabily test failed: Get http://foo.example.com/.well-known/acme-challenge/_selftest: dial tcp [here:goes:my:correct:ipv6:address]:80: connect: network is unreachable" context=acme domain=foo.example.com
2016-12-20T15:12:56.121006599Z time="2016-12-20T15:12:56Z" level=error msg="Error while process certificate requests: no domain could be authorized successfully" context=kubelego
The trick is that I can easily go to http://foo.example.com/.well-known/acme-challenge/_selftest from absolutely remote IPv6 machine. No autorization, nothing is required, just works.
According to
https://community.letsencrypt.org/t/support-for-ipv6-only-hosts/354/60 and https://letsencrypt.org/2016/07/26/full-ipv6-support.html
Pure IPv6 is supported. Unfortunately in this case I cannot plain IPv4, so I can only rely on IPv6.
Also I've looked through the code, it seems like the query is made not by Let's Encrypt, but by the code of Kube Lego.
I cannot kubectl into kube-lego container, as the containes is pretty stripped of shell tools, but I've logged in into neighboring container in the same machine as kube-lego and it can "curl" the url just fine
Btw, if this turns out hard to fix, can we make self-check optional? For example we give a way to disable it via flag
"fixed" it just for myself by throwing away self-check and building custom image. This is just FYI to show that this was the issue. Lets Encrypt issues the certificate without a problem
Hey @igor-petruk, how did you tackle building the custom image? I am running into a situation where the self-check is failing due to issues with NAT, but the service is perfectly reachable from the outside. Disabling the self check would help a lot.
Hi,
I've just commented out the check, built a custom image and I've put it into my internal docker registry. That check is probably formally needed by Let's Encrypt, but it is terribly unreliable.
2017-05-29 9:11 GMT+01:00 WillemdeKok [email protected]:
Hey @igor-petruk https://github.com/igor-petruk, how did you tackle building the custom image? I am running into a situation where the self-check is failing due to issues with NAT, but the service is perfectly reachable from the outside. Disabling the self check would help a lot.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jetstack/kube-lego/issues/66#issuecomment-304600456, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWTIMlyp4_-uWBObnw4wucKSGo-ymlQks5r-n2WgaJpZM4LR9As .