This topic has come up many times in the forums, so I know I’m not the only one struggling with it.
In many environments, it’s really hard (or even against policy) to open port 80 to the entire world just for ACME validation. Examples include:
servers that aren’t web servers (VPN, FTP, PBX, etc.),
internal-only servers,
servers locked down to a specific geo region or small user base,
financial institutions etc. with very strict firewall rules.
The problem: to use HTTP-01 validation today, we basically have to open port 80 to everyone, which goes against “minimum privilege” security practices.
I understand Let’s Encrypt’s policy is not to publish IP ranges and that they may change at any time. That makes total sense.
But here’s the idea: instead of publishing IPs, what if Let’s Encrypt provided a single DNS hostname (like validation.letsencrypt.org) that always resolves to the current set of validation servers?
Let’s Encrypt could still change IPs anytime, without notice.
Security is not reduced in any way.
But for admins, it would make firewall whitelisting possible without opening up to the whole world.
This would solve a pain point that keeps coming up in the community. I believe it could help many people adopt Let’s Encrypt in environments where current firewall policies make it very hard.
While I'm not an expert, I beg to differ with regard to this argument.
The main reason why Let's Encrypt already does validate from multiple vantage points around the world and why all publicly trusted CAs are required to do so in the near future. See section 3.2.2.9 of the CA/Browser Forum Baseline Requirements.
The reason for this multiple network perspectives validations are BGP hiijacking attacks to maliciously issue certificates with false validation.
While I don't like security by obscurity, not advertising the IP addresses that are used for validation, makes it possible to randomly switch the used IP address from which the hostname is being validated, making BGP hijacking even more difficult.
If the http-01 challenge isn't possible, there's always the dns-01 challenge, which can be delegated with NS or CNAME RRs to whatever host you feel comfortable with answering to the challenge.
Agree the DNS Challenge is usually best alternative. But, another possibility is the TLS-ALPN-01 challenge which uses port 443. Support for this by ACME Clients is more limited but some examples are Apache's mod_md, Caddy server, and the upcoming nginx-acme module for nginx.
I agree that the real defense against BGP hijacking is multi-perspective validation. The more independent vantage points are used, the harder it is for an attacker to consistently hijack them all.
By contrast, hiding the validator IPs provides, if any, only a very thin layer of “security through obscurity.” An attacker can easily set up test domains, request validations, and observe where the validation requests come from. So obscurity can be bypassed easily, while multi-perspective validation truly raises the cost of an attack.
That’s why exposing validator addresses under a single DNS hostname would not meaningfully reduce security. LE could still rotate, add, or remove IPs dynamically at any time.
As a possible compromise, such a DNS record could even include many decoy addresses in addition to the real validator IPs, maintaining ambiguity. This would preserve the “obscurity” aspect for those who value it, while still giving firewall administrators a concrete hostname to whitelist.
That’s true, but DNS-01 isn’t always a realistic alternative. It requires a more complex operational setup, it depends on the DNS provider offering an API, which isn’t always available. And it usually forces administrators to store DNS API credentials on the server, which is a serious security risk.
So while DNS-01 works well for some setups, it’s not universally feasible. That’s why having a practical HTTP-01 solution that still works with strict firewall rules would benefit many users.
Thanks for pointing out acme-dns. It’s a smart project. But it’s much more complicated than HTTP-01 and adds significant operational overhead.
Also, it doesn’t really solve the strict firewall problem: I’d still need to expose a local DNS service to the outside, which means writing firewall rules for DNS instead of HTTP. In practice, that just swaps one access-control headache for another.
That's the beauty of acme-dns: it's sole purpose is to respond to ACME requests, nothing more. And you'd only redirect the _acme-challenge label to the acme-dns instance: it won't influence the security of your main DNS in any way, thus acme-dns can run somewhere less secure.
Assuming your DNS zone itself isn't completely firewalled off to the world wide web, as the CNAME for the _acme-challenge label needs to be able to be resolved. Which usually isn't the case. If that is the case, maybe Let's Encrypt is not something you should be looking into, but perhaps consider e.g. a private CA you operate yourself.
I would second the suggestion by @MikeMcQ to use an application aware firewall and allow /.well-known/acme-challenge requests over http, to allow all HTTP domain validation to work.
Regarding DNS challenges, if you need a certificate from Let's Encrypt your domain must have a public DNS service, even if you have an internal DNS service for the "real" usage of the domain. Otherwise HTTP domain validation definitely wouldn't work either.
If the problem is you don't want to share DNS credentials across servers there are strategies for that as well.
Eventually if you are looking at whole-organization certificate you will need to move away from http domain validation, because as you say many services are internal or not web services. You may also consider running an internal CA, which also means domains can be pre-validated,
That’s an interesting idea, but not every firewall supports filtering by request URL, so that’s only a partial solution.
Also, if the server isn’t really a web server, I’d prefer to keep port 80 closed entirely, rather than expose it even for a specific path. Opening it globally - even if only for a certain URL pattern - still leaves an attack surface in case some exploit is found.
And most importantly: This feature request could make things easier for many people. I’m definitely not the first, and won’t be the last, to ask for this. It seems to be one of the most requested features in this community. Alternatives like DNS-01 or special firewall rules certainly exist, but they don’t fit every case. I think it’s worth discussing the proposal itself, rather than only pointing to workarounds.
I’d be very interested to hear thoughts on the idea itself, since it could benefit many users.
Sure, you'll need to wait for a response from an LE staffer as only they can say whether they would provide that hostname in DNS (which in turn would effectively be a list of published IPs in DNS, albeit a temporary combination). I'm pretty sure they don't currently have DNSSEC enabled however.
Sure, but, many people posting here don't know all the possibilities and benefit from hearing solutions to specific problems.
For example ...
Firewalls like that do exist so you've learned something from discussing workarounds
Perhaps all firewalls should have such features. The solution you propose only helps people who use LE as their CA.
We've seen similar ideas discussed before and I don't think LE will prioritize such a thing. I am just a guy and don't have any special influence on their schedules. As webprofusion noted you'll have to wait for comments from staff about that. If they express interest you'll probably get more varied comments / concerns about the specifics.
But here’s the idea: instead of publishing IPs, what if Let’s Encrypt provided a single DNS hostname (like 