DanielDent
commented
5 years ago Hi Clayton -- thanks for the pull request. I agree there is value in having a safety check like this. I thought that doing this was built into the ACME client -- perhaps it used to be (at some point in the history of this project, the ACME client got swapped out for a different one). I've had this on my agenda to address at some point, but haven't yet made the time.
I think a much better safety would be to somewhat emulate the acme protocol by placing a file with random contents at a random location under the ACME .well-known path -- and while we are at it, I'd see value in ensuring that multiple consecutive checks pass, to help mitigate issues where e.g. one load balancer is correctly configured, but other load balancers in the rotation have not yet caught up to the working configuration.
My core concern -- there's lots of misconfiguration situations where you'll get a valid 200 response from a domain's root, but it isn't actually routed to this container. Likewise / could be returning a 500 response, but the correct behaviour may still be to issue get the SSL certificate issued regardless.
claytondaley
This is an initial effort to resolve #19 by ensuring that something is responding at the requested domain before proceeding to the Let's Encrypt step. This should reduce the odds of tripping rate limits while the DNS is improperly configured (e.g. when new AWS ECS tasks are assigned arbitrary IP addresses).
I've tested this in ECS and it's working. If a server cannot connect to itself at its own DNS entry, this check will forever fail. It may make sense to add support for an environment variable like SKIP_DNS_CHECK that may be called to skip this section (but my bash-fu is weak so I did not attempt it).