It appears to me that /.well-known/acme-challenge/_selftest will respond 200 OK even when the Host header is for a host that is not configured on the ingress controller. However, if the Host header is set to a something that is not known when requesting /.well-known/acme-challenge/token, where token is the authorization token acme is requesting, kube-lego will return a 404.
Proposal:
../_selftest follows the same rules that the ../token resource require.
Issue:
I was using NGINX to proxy pass acme challenges from what was in production to the newly configured ingress controller. That way I could get the cert, then move DNS and I wouldn't have any downtime.
I failed to configure a proxy_set_header Host $host; line that would have set api.stage.example.com in the Host header. This caused nginx to send an unknown hostname along to my new kube-lego controlled ingress. Which meant that kube-lego would return a 404 when acme challenged. I would have noticed the error in my nginx configuration had my test of the _selftest endpoint not returned 200 OK. This isn't all kube-lego's fault though. I caused a lot of heartache for myself by defining the kube-lego as the default backend for the ingress controller. Doing that meant when the LB didn't know what to do with a unknown Host header, it would send it on to kube-lego. Kube-lego didn't check the header to see if it matched, like it must for challenges, and just said 200 OK.
So don't make kube-lego your default backend, and maybe we can get _selftest to act like the token challenge URI.
Description:
It appears to me that
/.well-known/acme-challenge/_selftestwill respond200 OKeven when theHostheader is for a host that is not configured on the ingress controller. However, if the Host header is set to a something that is not known when requesting/.well-known/acme-challenge/token, where token is the authorization token acme is requesting, kube-lego will return a 404.Proposal:
../_selftestfollows the same rules that the../tokenresource require.Issue:
I was using NGINX to proxy pass acme challenges from what was in production to the newly configured ingress controller. That way I could get the cert, then move DNS and I wouldn't have any downtime.
dns--[api.stage.example.com]-->load_balancer_a-->nginx--[proxy_pass]-->load_balancer_b-->kube-lego
I failed to configure a
proxy_set_header Host $host;line that would have setapi.stage.example.comin the Host header. This caused nginx to send an unknown hostname along to my new kube-lego controlled ingress. Which meant that kube-lego would return a 404 when acme challenged. I would have noticed the error in my nginx configuration had my test of the_selftestendpoint not returned200 OK. This isn't all kube-lego's fault though. I caused a lot of heartache for myself by defining the kube-lego as the default backend for the ingress controller. Doing that meant when the LB didn't know what to do with a unknown Host header, it would send it on to kube-lego. Kube-lego didn't check the header to see if it matched, like it must for challenges, and just said200 OK.So don't make kube-lego your default backend, and maybe we can get
_selftestto act like the token challenge URI.