Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
AlmaLinux 8.1
My hosting provider, if applicable, is:
SecureLink
I can login to a root shell on my machine (yes or no, or I don't know):
No
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
SecureLink VPAM (https://securelink.challiance.org)
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Do you have a specific question or is this just a spammy post?
Let's Encrypt validates from aroud the globe so no, you shouldn't geoblock HTTP access to the path /.well-known/acme-challenge/ and no, Let's Encrypt doesn't provide a list of IP address.
We really do need to employ geoblocking outside the US due to all the hacking attempts that occur to access our network. Is it that Letsencrypt.org has completely eliminated the US sites, or supplemented them with sites outside the US? If it's the former, then I would expect our site's cert renewal to take place rather than fail altogether. If not, then we'll need to seek an
alternative certificate resource.
Is it that Letsencrypt.org has completely eliminated the US sites, or supplemented them with sites outside the US?
LetsEncrypt checks the challenges from multiple vantage points around the world. This is to minimize the risk of routing attacks. The IPs are unpublished because they are subject to change at any point in time.
You have 2 options:
1- Use the DNS-01 challenge. this is best combined with delegating the _acme-challenge DNS record onto a secondary DNS system (via CNAME), to sandbox the credentials away from your main DNS systems. You can use a hosted acme-dns instance or a secondary commercial vendor.
2- Use the HTTP-01 challenge, but disable the firewall rules during the certificate ordering process. This can be done with the pre/post hooks in certbot, or wrapping clients without hooks in a script that disables/re-enables the rules as needed. iptables chain rules work very well for this purpose. The firewall only needs to be disabled during the challenge phase.
NP. FYI, The CA/B forum is likely to mandate ALL Certificate Authorities perform multiple perspective validation within the next 2-3 years; support has been growing amongst it's member for an amendment to the Baseline Requirements covering this. Unless you are considering a Commercial CA who will not use ACME to issue your certificates (which are increasingly getting shorter in max duration), I strongly suggest you invest the time now to address this on your infrastructure and not defer the task or create new technical debt.
I shared some quick notes on using handling this with standard linux iptables here:
There are more detailed posts by others on this site as well.
It actually did pass unanimously, with requirements kicking in starting next month, and growing to needing at least 5 remote perspectives by the end of 2026.
Another option is to leave the geo-restrictions in place on port 443 and remove them only from port 80. You can then redirect all non-ACME traffic from port 80 to port 443. This will allow your HTTP-01 challenges to succeed without exposing you to any malicious access attempts.
That only works if the concern is over HTTP traffic; many people geoblock all traffic from certain regions due hacking attempts on every major port and protocol.
Yeah, but which exploit will exploit a HTTP to HTTPS redirect and/or serving of a static file? Usually dynamic languages such as PHP and their webapp implementations are targeted. Or stuff like SSH or OpenSSL. But those are not applicable for a simple HTTP responder.
I'm quite certain a very, very small and negligible attack vector remains when you open a HTTP to HTTPS redirect and just a simple static file to the world.