# LetsEncrypt IP Addresses... It's Actually pretty important **URL:** \ **Category:** Feature Requests\ **Created:** [July 29, 2020, 10:58pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760 "2020-07-29T22:58:22Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![TravisR](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/travisr/32/41435_2.png) [@TravisR](https://community.letsencrypt.org/u/TravisR)\ **Post date:** [July 29, 2020, 10:58pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/1 "2020-07-29T22:58:22Z")
I know this issue has been touched on before in the past by other users and I am aware of your current stance on the issue, but it’s actually rather important issues and it does warrant some additional considerations. This would be a published list of IP address that Let’s Encrypt uses to do validation checks. I find myself in need of this very list. I have a sensitive system that’s a legacy system that I’m not permitted to make any changes to. Due to the nature of the services performed on this system, access to this system has been totally firewalled off to only specified static IP’s. That is until I have to manually open up port 80 to the entire world every couple of months in order to let Let’s Encrypt do its renewal and then close the system off once again. It wouldn’t be so bad if I could simply script the firewall rules on the system itself, but as I stated, I’m not permitted to make any changes to it. However, if Let’sEncrypt would pick a set of IP addresses, stick with them, and publish said list, users could easily add firewall exceptions that would allow for automated renewals without having to manually go in and fiddle with the firewall and run manual renewals every couple of months. I don’t want you to feel as if I’m unappreciative of the service you’re performing, I think its a wonderful contribution to the community and have personally made donations in the past as a thank you for the time and effort you’ve put into giving us all this tool to use, but I really feel that whatever reason it is that you have that’s preventing you from doing this, is greatly outweighed by the number of people who would be greatly benefited from it. The entire point of the system is to help bring security and encrypt to the masses, but then requiring unsecured ports be left open and exposed to the entire world in order for it to function really seems like it’s defeating the purpose. Users shouldn’t have to open up security holes in order to secure their systems. Just my point of view and a feature I’d really make use of. Feel free to flame at will. ---
**Author:** ![stevenzhu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/stevenzhu/32/18864_2.png) [@stevenzhu](https://community.letsencrypt.org/u/stevenzhu)\ **Post date:** [July 29, 2020, 11:10pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/2 "2020-07-29T23:10:42Z")
Disclaimer first: all contents are personal, I'm not affiliated with Let's Encrypt or ISRG. > [@TravisR](#): > > It wouldn’t be so bad if I could simply script the firewall rules on the system itself, but as I stated, I’m not permitted to make any changes to it. I think you could always attempt to get the certificate via DNS validation, which definitely don't need HTTP port 80 access. > [@TravisR](#): > > The entire point of the system is to help bring security and encrypt to the masses, but then requiring unsecured ports be left open and exposed to the entire world in order for it to function really seems like it’s defeating the purpose. Users shouldn’t have to open up security holes in order to secure their systems. I don't think port 80 will be a security hole if you already have other ports open (if you don't have other ports, probably DNS based will be better in your use case if allowed). As many people suggested before, port 80 is a common port and in most cases only serve as a redirection port nowadays. I think what Let's Encrypt want for not disclosing a list of IP and multi-va are all for avoid much worse security vulnerabilities (spoofing, for example), and Let's Encrypt provides at least another way for you to complete these challenges (through DNS TXT records, which can be used with acme-dns or something else if your company don't allow you to modify current NS/API). I know these can be hard for large corporations and some sensitive business / government, but HTTP based validation isn't your only choice. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [July 29, 2020, 11:11pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/3 "2020-07-29T23:11:00Z")
Plenty of users make use of the [DNS challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) to secure hosts that are completely isolated from the public internet. Even if your DNS host does not provide an API, something like acme-dns or a simple CNAME has the potential to provide a solution. Let’s Encrypt is definitely asking users to do more work/be more creative in these kinds of situations, but an IP whitelist is something that would basically tie their hands for the rest of existence. ---
**Author:** ![TravisR](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/travisr/32/41435_2.png) [@TravisR](https://community.letsencrypt.org/u/TravisR)\ **Post date:** [July 29, 2020, 11:13pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/4 "2020-07-29T23:13:58Z")
I will have to look into this again, but I believe that the DNS validation is a feature that was added in a much later revision of certbot than I am currently able to utilize on this system. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [July 29, 2020, 11:16pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/5 "2020-07-29T23:16:14Z")
A common practice is to put a reverse proxy in front of a legacy system, to ensure that the externally-facing webserver does not have any HTTP vulnerabilities and uses a modern TLS configuration. It would also mean that you can run a modern ACME client. ---
**Author:** ![stevenzhu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/stevenzhu/32/18864_2.png) [@stevenzhu](https://community.letsencrypt.org/u/stevenzhu)\ **Post date:** [July 29, 2020, 11:18pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/6 "2020-07-29T23:18:51Z")
To be honest, if you are using certbot you are being somewhat limited. It’s indeed the suggested client but not the only client. certbot has DNS challenge for a long time, but since most of times DNS API might not be up to date, you might need to write your own validation and cleanup scripts for your DNS API. There are definitely more clients (might even more popular than certbot for some DNS providers). ---
**Author:** ![SilverbackNet](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/silverbacknet/32/1032_2.png) [@SilverbackNet](https://community.letsencrypt.org/u/SilverbackNet)\ **Post date:** [July 29, 2020, 11:27pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/7 "2020-07-29T23:27:00Z")
I’m curious, but why are you restricted to a certbot that’s at least two years old (if you can’t use DNS challenge), but still hoping for LE to update in a way that’s very restrictive for the future maintainability of the service? ---
**Author:** ![TravisR](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/travisr/32/41435_2.png) [@TravisR](https://community.letsencrypt.org/u/TravisR)\ **Post date:** [July 29, 2020, 11:27pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/8 "2020-07-29T23:27:42Z")
That is a very good suggestion. I don’t trust this system at all. It was designed and written many… many years ago on an OS that’s been dead and EOL for at least a decade. I honestly wish I could just pitch it and be done with it. ---
**Author:** ![SilverbackNet](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/silverbacknet/32/1032_2.png) [@SilverbackNet](https://community.letsencrypt.org/u/SilverbackNet)\ **Post date:** [July 29, 2020, 11:32pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/9 "2020-07-29T23:32:05Z")
If it’s that bad, I’d just map the IPs each daily renew attempt and maybe drop off IPs that haven’t shown up in 60 days or so. If you lookup right before a request, chances are very good it’ll be the same IP each time, and eventually within in the 90 days it’ll definitely be. ---
**Author:** ![TravisR](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/travisr/32/41435_2.png) [@TravisR](https://community.letsencrypt.org/u/TravisR)\ **Post date:** [July 29, 2020, 11:49pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/10 "2020-07-29T23:49:20Z")
It was the only version that I was able to come anywhere near close to getting working on a ancient version of AIX. ---
**Author:** ![stevenzhu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/stevenzhu/32/18864_2.png) [@stevenzhu](https://community.letsencrypt.org/u/stevenzhu)\ **Post date:** [July 29, 2020, 11:59pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/11 "2020-07-29T23:59:12Z")
The issue is, it won’t. The daily renew attempt connect to Let’s Encrypt API server (which I think it’s behind Akamai or Cloudflare or some other CDN). The validation servers are another pool of servers that probably aren’t using the same IP for two validations (just like a random lottery) ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [July 30, 2020, 12:35am UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/12 "2020-07-30T00:35:34Z")
I’m going to give you an ipv4 subnet that includes all Let’s Encrypt validation servers: `0.0.0.0/0` And the equivalent ipv6 subnet: `::/0` (Yes, they include _the entire internet_, that’s the ~~joke~~ point.) If you can add firewall exceptions these should work. (Use the DNS challenge, using exceptions on those subnets effectively turns the firewall off.) ---
**Author:** ![ski192man](https://avatars.discourse-cdn.com/v4/letter/s/3da27b/32.png) [@ski192man](https://community.letsencrypt.org/u/ski192man)\ **Post date:** [July 30, 2020, 4:14am UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/13 "2020-07-30T04:14:37Z")
> [@TravisR](#): > > It was the only version that I was able to come anywhere near close to getting working on a ancient version of AIX. Maybe try something like acme.sh? It's written entirely in shell and supports DNS-01 validation > **[GitHub - acmesh-official/acme.sh: A pure Unix shell script implementing ACME...](https://github.com/acmesh-official/acme.sh)** > > A pure Unix shell script implementing ACME client protocol - GitHub - acmesh-official/acme.sh: A pure Unix shell script implementing ACME client protocol ---
**Author:** ![bruncsak](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruncsak/32/18414_2.png) [@bruncsak](https://community.letsencrypt.org/u/bruncsak)\ **Post date:** [July 30, 2020, 5:19am UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/14 "2020-07-30T05:19:20Z")
> [@TravisR](#): > > I don’t trust this system at all. It was designed and written many… many years ago on an OS that’s been dead and EOL for at least a decade. I honestly wish I could just pitch it and be done with it. If you have this old system, do not try to put anything onto it. Not even an ACME client. Put a recent/decent system next to it, do all the stuff needed, and just transfer the result to the old system. Target the phase-out of the old system: remove everything you can remove. Leave only the core stuff which forces the system alive. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [July 30, 2020, 6:15am UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/15 "2020-07-30T06:15:04Z")
1. Let’s Encrypt unfortunately can’t accomodate **every** use case. 2. You’re not allowed to make any changes to the system, but you _are_ allowed to install ACME clients and TLS certificates? 3. This system sounds like something which should _never_ be allowed to contact the internet directly, but always through a dedicated server with firewalls and such. In that case, you can always terminate the TLS connection on that firewall and let that firewall deal with the renewal of the certificate. (For example, with [Hitch](https://hitch-tls.org/).) No need to open your sensitive system to ACME challenges that way, as it will be dealt with one step up the ladder. Assuming the connection between the sensitive system and firewall is physically secure (i.e., no-one can do a MitM attack at the UTP level) and you don’t require end-2-end encryption directly to the sensitive service. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [July 30, 2020, 3:01pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/16 "2020-07-30T15:01:07Z")
In addition to the slew of other suggestions in this thread, OP might also consider that the safety of this legacy system might not make it the best fit for a Let’s Encrypt certificate at all. Pay for an annual cert from a traditional CA and be done with it. ---
**Author:** ![ndilieto](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ndilieto/32/31359_2.png) [@ndilieto](https://community.letsencrypt.org/u/ndilieto)\ **Post date:** [July 30, 2020, 3:22pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/17 "2020-07-30T15:22:18Z")
You can use TLS-ALPN-01 validation, which requires only port 443 to be open. Check [https://github.com/ndilieto/uacme#tls-alpn-01-challenge-support](https://github.com/ndilieto/uacme#tls-alpn-01-challenge-support) ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [July 30, 2020, 3:22pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/18 "2020-07-30T15:22:51Z")
Clarifying some suggestions above: 1. You could run a gateway server or firewall rule in-front-of this system, or a redirect. The system itself does not need port-80 access, you just need port-80 access running on the ip the domain names(s) resolve to. The entire `/.well-known` directory could be served on the gateway, or proxied/redirected to another machine. Then you can just copy/install the certificates OR have that gateway system function use the certificate itself. 2. DNS authorization is really your best option: - install `acme-dns` on a public internet machine - configure dns records to use that as your acme challenge mechanism - run certbot on your own machine to provision the certificates. it will coordinate the acme-dns and letsencrypt APIs - copy the certificates from your machine onto the legacy server. once you have the dns stuff configured, it is pretty stable. you could write a small script to run on your machine that does renewals for you, then restarts apache or whatever on the legacy machine. this is essentially what i do with our internal servers. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [July 30, 2020, 3:32pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/19 "2020-07-30T15:32:19Z")
> [@rmbolger](#): > > In addition to the slew of other suggestions in this thread, OP might also consider that the safety of this legacy system might not make it the best fit for a Let’s Encrypt certificate at all. Pay for an annual cert from a traditional CA and be done with it. Could you please explain _why_ a Let's Encrypt certificate isn't the best fit? Now it sounds like payed certificates _themselves_ have an extra security benefit above Let's Encrypt certificates. Which of course is not the case. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [July 30, 2020, 4:12pm UTC](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760/20 "2020-07-30T16:12:37Z")
> [@Osiris](#): > > Could you please explain _why_ a Let’s Encrypt certificate isn’t the best fit? Now it sounds like payed certificates _themselves_ have an extra security benefit above Let’s Encrypt certificates. Which of course is not the case. Sorry about that. I should have been more explicit. If OP's organization has decided this system is so fragile that they must disallow admins from making "any changes to it", an ACME client should not even be added to begin with. A paid certificate where all of the validation can happen outside the fragile server is the least intrusive to its config and they would only have to touch it once a year. (We'll conveniently ignore the fact that installing a new certificate is a change to the system regardless of whether a human or an ACME client does it) [Next page](https://community.letsencrypt.org/t/letsencrypt-ip-addresses-its-actually-pretty-important/129760.md?page=2)