As is well known, many ACME clients using HTTP01 auth require port 80 to be free, otherwise it needs compatibility options (such as ngnix) or temporarily shut down the program that using port 80
I am planning to use iptables to redirect requests from to 80 to another port when requesting for a certificate, so that there is no longer a need to control programs that use port 80 (as it may be various different software).
However, I am planning to go further by using the source address of the request for redirection. If we can redirect only requests from Let's Encrypt based on the source address, then the service on port 80 does not even need to be paused. This iptables rule can also be retained indefinitely instead of being temporarily added and deleted.
I am planning to manually collect these IP addresses, but it would be great if there were an official list available
There is no list available, for the same reason as there's no list available for the servers from which LE attempts HTTP validation.
It sounds like you're trying to work around some sort of problem, but it's not clear to me what problem that is. Usually, you can have your client integrate with your web server on port 80, or the web server running on that port has an ACME client built in, or something like that. Usually all that needs to happen on port 80 is handling ACME challenges and redirecting all other requests to https, so it can even be a different piece of software than that which runs the "main" site on 443.
If you're in some unusual situation where you can't put some sort of ACME-aware reverse proxy or the like on port 80, you might want to look at some experimentation from a couple years ago which configured Linux to intercept requests for the HTTP challenge in order to reply to them without interfering with normal web serving. I don't know if it's mature enough for "production" yet, but it was an interesting idea.
In terms of can you "manually collect these IP addresses", you'll basically be collecting every external IP used by VMs hosted in AWS, and potentially other clouds eventually too. Let's Encrypt needs to check from multiple places around the world in order to make sure that you control the domain name as seen from around the world, so they regularly spin up VMs in various regions to do validations.
In fact I'm writing a script that helps people getting cert via http01 no matter what program running on port 80.
For a long time, I have been suggesting using DNS01. But let's encrypt is going to issues ip cert with tls01 and http01. So I think the number of people with this demand will increase.
If all requests are only AWS, then redirecting all requests from AWS is probably acceptable (assuming the validation requests come from EC2 instances around the world)
Even if all the requests come from AWS today, you shouldn't count on them coming from AWS forever. You should design around the premise that they could come from anywhere in the world.
And, they don't all come from AWS today either 
HTTP-01 authentication must happen on port 80, as that is required by ACME Servers due to the ACME RFC and the CA/B Forum.
I am planning to use iptables to redirect requests from to 80 to another port when requesting for a certificate,
There are 2 standard ways to handle this, scoped to the /.well-known/acme-challenge path of the webserver
1- redirect onto another server
2- proxypass onto a listener, such as Certbot's standalone plugin binding to an alternate port with the --http-01-port={PORT} commandline option.
Another standard technique is to use pre/post hooks on Certbot to drop/replace firewall rules.
If you really want to handle with traffic shaping, there is a linux kernel plugin authored by a Certbot maintainer: GitHub - alexzorin/certbot-standalone-nfq: HTTP authenticator plugin for Certbot which is compatible with any web server!
However, I am planning to go further by using the source address of the request for redirection. If we can redirect only requests from Let's Encrypt based on the source address, then the service on port 80 does not even need to be paused.
Please do not do this. This is an anti-pattern and officially recommended against by the LetsEncrypt staff.
Their IP addresses are subject to change at random: the number of validators, their locations and their networks are considered to be ephemeral and ever changing. You would only making be code that will eventually break and everyone at ISRG and volunteers here will recommend against.
What IP addresses does Let’s Encrypt use to validate my web server?
We don’t publish a list of IP addresses we use to validate, and these IP addresses may change at any time. Note that we now validate from multiple IP addresses.
Usually the service on port 80 doesn't need to be paused. In fact, it can be utilised to perform the http-01 challenge to begin with.
So while you're thinking about public IP lists and source addresses, I believe that is most likely not necessary and all complex solutions are most likely also unnecessary.
Yes, I know that. That's why I make redirection instead of asking "Is there anyway to verify via other ports"
Thank for information, I think I should just redirect all request temporarily.
It's not too hard to figure out the IP blocks we use, if you were so inclined, but we don't maintain a list and don't provide support for doing that, and they could change without warning.
In particular, we use AWS auto-scaling groups for MPIC (aka secondary validation, aka remote validation), which churn through IPs daily, so you'd have to get lists from them and keep them updated.
That is the best option. All requests will happen within the /.well-known/acme-challenge directory, so you just need to handle that path.
The requests will only happen while certs are being processed, so you can use iptables chains to reroute traffic only when Certbot (or whichever client you use) is running.
This comment has my install notes for ip-chains rules:
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.