Skip to content

PreCheck Domain to avoid Let's Encrypt Rate Limits #23

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 26, 2019

Conversation

claytondaley
Copy link
Contributor

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

…eding to let's encrypt verification (to avoid rate limits, see issue DanielDent#19).  Note that `dns-servers` flag would be ideal but is not available.
@DanielDent
Copy link
Owner

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
Copy link
Contributor Author

Agree with everything you say. I'm +100 for improvement. Unfortunately, my bash-fu is poor so I wanted to keep my change simple but useful. This addresses the most extreme case (system inaccessible).

@DanielDent DanielDent merged commit 1d9a4f9 into DanielDent:master Apr 26, 2019
@DanielDent
Copy link
Owner

Thanks Clayton -- I've merged this for now but re-opened #19 to keep track of this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ensure Container is available at Domain Name before proceeding to Let's Encrypt Checks
2 participants