Too many failed authorization attempt errors

[Whitestrake (Matthew Fay)]

@Yespire

Would it be helpful if Caddy has some logic to verify host is “reachable” by configured domain prior to attempting Letsencrypt process? (however users should ensure this, but mistakes happens)

There are so many variables here that in short, the only way to ensure your host is reachable by LetsEncrypt is to be LetsEncrypt and try to connect. Other than that, only trying an ACME challenge is going to tell you definitively whether an ACME challenge will succeed or not.

Everything else is too affected by the local environment for any client-side automatic testing to be reliable, even if there were multiple indicators that could be used in concert to determine confidence. Matt’s written a bit about this recently in another thread, too:

@matt

If you can’t verify your setup manually for whatever good reasons, then automated checks will require some significant effort on your end, which are still not guaranteed to be accurate predictors. For that reason we don’t recommend this. But if you insist, you’ll need one or more (preferably multiple) external vantage points, or in other words, servers outside your site’s network (and preferably on a different provider and in a different region). They’ll need to run ACME servers. Then from each of the machines you want to validate, you’ll need to conduct an ACME transaction with each vantage point. This causes your ACME servers to perform authoritative DNS lookups for your domains and, depending on the challenge type, establish special TLS or HTTP connections with your machines (or none at all if using the DNS challenge). If all of that works and your own ACME servers can issue a certificate, then it is likely (but not guaranteed) that Let’s Encrypt will, too.

This gets even more tricky considering the nuances of individual DNS providers, which have different propagation times and other guarantees (or lack thereof).

That’s a lot of work for very little reward, so we recommend just making sure that your ports are configured properly and your DNS records, too.

And there’s also this draft for industry standard ACME client best practices that warns against relying on this kind of checking: docs/acme-ops.md at master · https-dev/docs · GitHub

Essentially - you find me some logic that might be helpful, and I can probably find you a use case that renders that logic invalid (and possibly counterproductive).