Description:

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.

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