Perhaps this topic is already discussed but I did’nt find any information in forum or by search engine…
For a firewall setup on Domain-Site that is configured in whitelisting manner the client possibly can’t connect like in my first tests. The Cert build completed successfully when I opened port 80 completely for the time of building the cert. Having in mind to automate the process of LE I would like to be able to put a rule in iptables for those defined IP addresses that LE is using to validate.
In case I missed the docs regarding this topic I’m sorry to bother the forum.
yes, need this too, but better way would be if there is a way that the LE asks external DNS records for validation. I need also certs for internal services which aren’t available from external.
If they are going in a firewall rule somewhere that means the LE team needs to acknowledge they aren't going to change, which is different than just YOLO-ing it up
We plan to frequently change the set of IPs from which we validate, and will validate from multiple IPs in the future. Any host answering challenges should have port 80 or 443 available to the Internet.
You can just query the DNS entries for that, you don't need SSLLabs. Additionally, that shows you the IP of the API server, not necessarily the Validation Authority. As @jsha already said, IPs will change and be multiple ones in the future to reduce attacks to specific routes.
For me it isn't about the ports being open or not, I want to use iptables REDIRECT rules for mediating access to the ACME client. The avoids a lot of the issues where the normal LE client has to have deep knowledge of the web server and config being used. I can do it without that by making it a transparent proxy (which is my backup plan) but it would be faster to be able to only intercept the traffic from the validation IPs.
I have a similar want. Right now we have bitbucket calling the single public IP address on port 80 to activate web hooks that trigger CI builds.. Traffic to port 80 from bitbuckets provided network ranges is routed to the CI server.
If you want your server to check that the payloads it receives are from Bitbucket, whitelist these IP ranges:
131.103.20.160/27
165.254.145.0/26
104.192.143.0/24
Any other IP on port 80 does nothing.
Even if there was one or multiple network ranges provided - it would allow adding a rule that redirects just the letsencrypt traffic as desired.
I am also looking for this capability. Please reconsider your stance on this as I suspect a large number of potential users will want this. I don’t want ports 80 / 443 open to the entire Internet on most things I would use Let’s Encrypt for. In my current use case, I have to make a request to another team to open the ports for each system, and I need to justify why I want those ports open to “everyone”. I also have to make requests to the other team to close those ports again. If I can just have them open a range of IPs for Let’s Encrypt, it’s simple to just leave those in there and update them as they change. If things break because we have not kept them updated, that’s on us. If the process doesn’t work at all because you refuse to publish the list of source IPs and your requested configuration violates the organizations security policies, then we are at an impasse.
To me the aims of LE is to provide certificates for domains ( from the number one on their list “Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.” ). To do that they need to prove ownership of a domain, and it’s primarily for securing public domain names … anything that enables someone to port forward / proxy etc makes it more difficult for LE to determine accurately and automatically that you are the rightful owner of that domain.
If your requirement is not for securing your public facing domain name - then it’s not LE’s top aim, and there may be other certificate providers that do other checks of your rightful ownership of the domain which might be more appropriate for your use.
I’d like to ensure that LE certfificates are trusted on my public facing websites, and would hope they do nothing that increases the risk of losing that trust …
Our motivation to know the range of IP addresses LE validation originates from is primarily security driven but practical requirements are reasonable too, also mentioned by other users in this topic.
I think a lot of deployments of webservers are kind of
That means doing port forwarding is widely used but in my opinion that does not mean the risk of losing trust for LE.
LE certs are domain validated - no more, no less. The DNS infrastructure resolves domain name to IP address. What happens on the server with this IP-address can be anything and should not matter regarding the domain validation (perhaps I miss a lot of evil things that could undermine LE trustworthiness possible with port forwarding but I think those are existing risks anyway independant of knowledge of those IP addresses).
In our case we provide webbased applications to a clearly defined region and we filter the whole ip traffic via country-based whitelisting where possible to lower any risk of attacks. tcp 443 traffic that maches the souce whitelist is forwarded to a proxy (kind of web application firewall) that does proxying, balancing and stuff.
At this point port-forwarding besides security reasons comes into play in our case too.
The production proxy should not be paused when an automated process (also the aim of LE) renews the certs.
Further I think the automatic mode of the LE Client will not be usable in many deployments where no standard apache but a self compiled apache is installed in addition with special directory and file structures of configuration files.
To run in our setup we would have to modify the LE client but I think this is not our best option. Instead we plan to use the manual mode of the LE client in an automated routine that puts the certs after validation into the production configuration. It would be much easier to have a Webserver (apache for example) just for this validation process besides the production webserver. Requests for the LE validation would be redirected by the firewall to this LE-validation webserver – forwarding would ideally be based on a known IP address range that we are trying to ask for (kindly).
Changing the IP addresses often like @jsha pointed might be reasonable for example to make mtm attacks more difficult.
I still would like to either have a sensible not too big range of IP adresses or - even better - the possibility to automatically get a list of actually used IP adresses. Perhaps the LE client could be extended to be able to do such a request. This could also be included in the automated process.
BTW: Many thanks to Letsencrypt, my question here is quiete a detail that should not diminish LE’s efforts.
let me try a relatively simplistic scenario … that you have a front end firewall that port forwards all traffic from known LE addresses to a secondary server, for certificate validation as you suggest. If I wanted to be evil and nasty I could potentially target that firewall box and modify it to route all traffic from LE to a server I control. The chances are, you wouldn’t notice for quite a while as all the normal web traffic is hitting your server fine, and you don’t expect any LE traffic for another month … so I can happily produce some authoritative certs for your domain ( or sub domain)…
If there are many IP’s and they are constantly changing, not public knowledge then that becomes much more difficult, especially without you noticing that lots of your traffic is suddenly been diverted.
I am not part of LE, and don’t speak in any way shape or form for them. From my perspective though anything that makes the route to the legitimate domain on ports 80/443 different for LE than regular traffic that opens up a potential hole in the system ( and really your part of the system).
I read your scenario as “I’d like to redirect traffic from LE away from the legitimate domain to a special licensing server” which to me opens up that potential hole or route for someone to be nasty and evil with.
Meant in a positive constructive way - as I say, I may just be getting nervous and cranky seeing problems where there aren’t any
I would like to request if there’s public information about the ip ranges of the Let’s encrypt API’s. The reason is that I would like to white list them on websites that normally are protected with ACL’s.
Hi @maikell, as @jsha said, the Let's Encrypt CA does not want to announce particular IP addresses that are used in validation because of a desire to change them periodically (partly in order to make it harder for attackers to be able to cause misissuance). While you could figure out what addresses are currently used, they may change at any time and will not be documented. If you can't allow inbound connections from the general public to the service that you're trying to validate, you can use the DNS challenge type (which just requires letting the Let's Encrypt CA look up your DNS records associated with that name).
What about letting clients notify the Let’s Encrypt server on what port it should access the challenge files?
This would allow you to have a specific port just for LE and you do not need to open (/use) 80 or 443.
