We had issues validating via http, until we found out our Geo blocking rule in the Firewall was blocking the second validation attempt from LetsEncrypt.
The connections come from Singapore and Sweden, so we whitelisted them. Instead, we want to whitelist the IPs used in the letsEncrypt validation process
Is there any way to whitelist LetsEncrypt server's IPs instead of whitelisting the locations?
No, there is not, that would defeat the purpose of these (possibly changing at any moment) multiple vantage points.
Please see the following entry of the FAQ: FAQ - Let's Encrypt
If you absolutely need to block general incoming http requests consider whether you can instead allow all incoming http /.well-known/acme-challenge requests by inspecting http traffic at the firewall, this would allow http validation to work normally. Alternatively, use DNS domain validation instead of HTTP domain validation.
Thanks for the suggestion, I'll bring this up to our team and confirm if worked.
Under our current process, DNS validation creates more steps, dependencies and complexity. os HTTP validation is ideal.
Thanks again!
Update: This worked.
Thank you very much for pointing us in the right direction!
Can you please explain to me how you accomplished this? I'm missing something.
This was never an issue until recently. Now all of our renewals are failing. We have tried allowing both www.letsencrypt.org and www.acme-v02.api.letsencrypt.org via DynDNS in Juggernaut Firewall, but all renewals are still failing.
Maybe I misunderstood what @pracllc was saying. As he preferred http, I took his comment as he found a way to make that work. I'm at a bit of a loss in reading some of the documentation on DNS. Am I to understand that we can just add a CNAME record to our DNS files for each domain?
Sorry if that's something that should be obvious. I'm in no way a newbie to the servers, but this particular issue is out of my normal troubleshooting area.
@JimRockford
You might be experiencing a different issue; for personalized assistance you can make a new Help topic and fill out the form with the exact symptoms you're seeing and your domain name.
Having anything specific to Let's Encrypt's name on your inbound firewall rules won't help anything, they're checking from multiple places, not from the same server that your client is connecting to.
For general information on how to have firewalling work with Let's Encrypt continuing to expand the locations that they're validating from, you can refer to this FAQ:
My challenge is the GEO blocking issue. We have several fiduciaries on our server, and we have used GEO for 24 years. It's been a God send for protection as overseas IPs can't even see us. This is the first issue we have really had. I just need to figure out how to get these renewals to work without dropping what has become one of our top security protections, or I'll have to start turning it off to manually renew every single domain on our server every 60 days.
If there is a way to make renewals work via a published txt file, then that sounds like it would be the answer.
You need to allow worldwide access to either
whatevername.example/.well-known/acme-challenge over http (port 80)_acme-challenge.whatevername.example over dns (authoritative nameservers)I am not sure how this was accomplished, since this was executed by a 3rd party company. We just gave them the instructions of what we needed, and the info from these posts, then they made some changes based on the instructions, and we confirmed it was working
This was executed at the Firewall Level, not domain Level
Well, darn. So far, it's not sounding like there is a solution there for us. @pracllc thank you for the reply.
@9peppe I'm not sure I quite understand how I can make that happen. We're using Juggernaut for our GEO Blocking, and the blocks are at the firewall level so that one, we don't have to configure every single domain on the server individually, and two, it's an awesome security measure. We don't even get spam from overseas, much less trojans or hack attacks.
GEO blocks at the server level. We have tried whitelisting We have tried allowing both www.letsencrypt.org and www.acme-v02.api.letsencrypt.org via DynDNS in Juggernaut Firewall, but that's not allowing it either.
I'm not sure how to allow the two entities you mentioned. Perhaps I do some digging.
It looks like there are a couple of Youtube videos out there on how to create a file in the DNS records, but the two I have found so far are really bad, and it sounds like I may have to update them every 60 days. If that's the case, then I might as well just turn off GEO and manually update all of them every 60 days.
It's ironic that Let's Encrypt is a tool used for security, but to make it work, now we have to turn off our first line layer of security. It would seem like there would be a fix for this.
If you truly believe this statement, I also truly worry for the actual state of your security. It's often not difficult for attackers from regions you're currently blocking to launch an attack from a region you're NOT blocking. E.g., zombie machines taken over by the attacker or a cheap VM leased with a stolen CC from a country you're not blocking.
The main line of defence should be stuff like that all the software exposed is up to date and without any (known) exploits, don't use standard passwords (or even better, don't use passwords at all) and have all cryptography secure (e.g. no Debian weak keys). IMO geoblocking is just a tool to make your log files grow less fast due to futile automated brute force login attempts. Ultimately, it does not protect you from directed attacks.
There is, as already mentioned: allow the HTTP path /.well-known/acme-challenge/ globally. The fact not every security device can do this does not mean there is no solution.
The dns-01 challenge often is another workaround/solution.
You could always open up port 80 while leaving 443 filtered. Assuming that you have HTTP -> HTTPS redirection on all but your /.well-known/acme-challenge path, this would allow Let's Encrypt multi-perspective validation to succeed while still blocking web access from your unwanted origins.
It's just one layer that we use, but it's amazing how powerful it has been. We even use GEO at all the office firewalls, and it's been amazing when comparing to exploits that other title company and brokerage firms are dealing with.
I'll have to see if I can find some documentation to better explain what you're suggesting, because clearly I'm missing a step. Thanks.
You know what's even more powerful? Switching your servers off.
No attackers at all. 
(yes, you need a waf to filter based on path and domain)
That's very helpful. Thank you.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.