It benefits usability to have a challenge doesn't need to interfere any running software on client server, and while on BR's authorized ports (80,443,25,22) by far port 25 is least likely to be idle in most servers as usage of selfhosted mailserver are not popular in resent days due to aggressive spam filters, and most ISP level port 25 blocks outbound, not inbound connection.
while RFC 8555 forces validation starts on port 80, CA/B BR 3.2.2.4.18 (that uses .well-known/pki-validation dir) only requires MUST be accessed over an Authorized ports.
if someone do run this challenge method it shouldn't support redirect in this context, as http server on port 25 likely be dedicated standalone acme client, and less likely to happen some cross protocol attack.
and I thinks this is intended usage of this list of authorized ports, as no other challenge can use ports natively.
Even if the BRs technically allow for an HTTP challenge to occur on a non-80 port, the ACME spec is very clear that the http-01 challenge "MUST" be sent over TCP port 80.
Dereference the URL using an HTTP GET request. This request MUST be sent to TCP port 80 on the HTTP server.
So in order for this to work, you'd effectively need to define (and have implemented by ACME CAs) a new challenge type such as http-25 which explicitly tries the connection on TCP port 25.
I'm guessing the likelihood of this happening is slim. The currently accepted alternative to http-01 for folks who for whatever reason can't host directly host an HTTP challenge on port 80 is to use dns-01.
I do think a port 25 challenge would be useful, but it would probably be a new smtp based challenge for mail servers to use, rather than HTTP. Maybe ALPN-01 after an SMTP STARTTLS.
Now would be the time to consider if Port 25 challenge should or should not have alternative Port choices.
What's a BR?
There's just no need for other challenge ports (from my perspective). With the right tools and the right DNS provider, DNS challenges are much easier than almost anything else, even easier than http challenges in many cases, plus they prove actual domain DNS control rather than just webserver control.
what's BR?
CA/Browser forum Baseline Requirements
I think while DNS challange provides most secure, however as most DNS provider give API on entire DNS zone so I think why people doesn't like to save DNS api on their webserver
Thanks, yes, the DNS providers that give more granular control over their API are best and sensitive credentials like that should be encrypted at rest.
DNS entries can be CNAMEd to any other zone.
[including sub zones of the same domain]
Like:
_acme-challenge.example.com CNAME deligated-sub-zone.for-acme-only.example.com
Given that API control keys can be restricted to a specific sub zone (or zones).
That would allow me to sleep at night 
If not, then I don't think a web server is a very good place to keep the keys to the entire DNS zone.
The remote controls the robot!
In many situations, the DNS API keys also control domain transfer and registration - which is why they are very very dangerous and acme-dns is almost always preferable.
Wishlist: I think it would be useful to propose a general "privileged port" ACME challenge that could only be run by Root/Administrator, and would either run on a dedicated port or be configured to run on anything under 1024 (assuming windows respects those assignments as well).
A use-case would be allowing for certificates used by the service running on Port 80/443 (or Port 25) to be renewed without the involvement or coordination of that service. The client could just bind to the port on demand (i.e. like the standalone Certbot plugin) and handle the entire certificate procurement process without requiring any configuration or downtime of that main web service. The main service could then receive a graceful shutdown signal to reload the certificates on success.
I deploy this pattern a lot by leveraging (i) global proxypass of acme-challenges to a higher port, and (ii) running certbot on a higher port with the standalone plugin. Getting the first part done takes some testing and coordination, this would eliminate that. This would create the same effect as using the acme-dns challenge - completely isolate the verification system from the service that utilizes certificates - but allows that to be done within a single application/process and a simplified pattern.
Building ACME verification into existing web/dns/etc services is great - but I think we'd experience a lot more overall utility from developing a secure dedicated ACME service/port.
I think that in practice this kind of system might as well just use port 53 (DNS), and there are clients like agnos which can fulfill DNS challenges. It's basically "standalone" mode just for DNS instead, just CNAME the _acme-challenge name to the same system you're getting a certificate for, and the client takes care of everything.
There are often situations where there exists a local DNS server (e.g. LAN addresses, local cache, etc) so that port is not available for an ACME client. My goal is to enable ACME challenges on a configurable privileged port.
One could also choose a port not already "claimed" as "the ACME validation port" and add that port to the BR as a valid one.
why I proposed http-25 challenge was it already allowed on BR so LE can do that which BR change.
if we are considering authorized port change, how about port 115(which was mistakeing simple ftp for ssh sftp), which was authorized port in BR until 1.5.1(SEP 2017)? (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.0.pdf)
Just to be clear, I am suggesting two things:
-
Create an ACME service that would run on a (relatively) unused trusted port by default. There are still some {insert service/port here} servers out there, but there are a large number of ports that have not been allocated or "well known" to be used by existing systems or protocols. This does have some limitations as non-unixlike systems may be able to bind to those ports. See: List of TCP and UDP port numbers - Wikipedia Note: it is common to host a SMTP relay server on port 25 and use that for sending mail instead of piping STDOUT to a "sendmail" binary.
-
Allow that challenge to be invoked on alternate ports. This could be a subset of well-known/reserved ports.
I am onboard with the idea of the existing HTTP challenge being usable on a mix of trusted ports: 20 (ftp), 23 (telnet), 25 (smtp), 80 (http) seem like a good group to start with, as there is a good chance someone can take at least one of those ports offline to handle certificate procurement. Ideally that range could be expanded to run on some of the more esoteric/unused ports in the reserved range. i.e. An RFC for "HTTP-02" might define it as the same as HTTP-01, except the challenge trigger URL allows a specified port to be submitted in the POST.
Perhaps the DNS record could be augmented with a CAA or TXT record that specifies which of the compatible ports are allowable for "HTTP-02" challenges on that domain. Unlike the DNS-01 challenge, the records would only need to be set up once and there would not be a need to set up complex zones to support delegation.
Building challenges into existing protocols is great, but that approach raises the possibilities of downtime or introducing configuration errors that are not caught. Being able to procure a Certificate via a (i) single service that is (ii) isolated from running services and (iii) relatively easy to configure would eliminate many issues.
As an aside, this is how windows based ACME clients generally do port 80 http-01 challenges because windows supports http pipeline sharing via http.sys - you can just add a listener for http:///acme-challenge/ that your acme service takes care of, so that request never reaches the web server service. The only time that doesn't work if you have a non-windows native service bound to port 80 (like Apache or nginx, or certbot standalone) because they want exclusive port 80 for their own http handler.
To get similar results on linux etc you could run an ACME aware proxy on port 80 back to your actual web server of choice, it does add a hop in your http requests to some extent though.
I should add regarding DNS credentials, of course if you are using DNS validation there is no need to perform your certificate renewals on your webserver, instead you can do it on an internal server dedicated to the job.
You can then either deploy from there or store certs in a secrets store and have your web servers (which nowadays are probably fairly transient container instances pointing to storage for the real content and config) pull only the certs they are entitled to by their respective credentials.
I would also endorse this idea. But I'm afraid that many people would try to use it in environments where port 25 is blocked (and they don't even realize it, since they've potentially never tried to use port 25 for anything before).
If this is ever deployed, I would favor have a special error message that mentions (or links to a page mentioning) the idea that your ISP may not allow connections on port 25, even by default in a data center with a VPS or colocated server, and that there's no way to work around this with that challenge method, without getting the ISP to change its policy or add a special case rule for a specific account or server.
I don't really have actual data about this, but I'm guessing inbound port 25 is about 10× more likely to be blocked on a residential account than port 80, and might also be blocked in default firewall policies of the majority of VPS services.
I suspect you're actually far underestimating it, at least for people likely to run ACME clients: Blocking port 25 is very common (especially outgoing, but blanket 25 bans are pretty common), but blocking 80 inbound is relatively uncommon.
But if you're running a mail server and want to accept mail on 25, you're going to have to deal with that anyways, which is why I think an ACME-SMTP on 25 might make sense, but that reusing 25 for other things (like an alternate HTTP challenge port) would not.
Yes. As a default, I implement that in nginx with a config macro included in all location blocks; it just proxies /.well-known/acme-challenge onto a higher port. Nginx is rather compatible with this design, because I can just alter the include port in one file and do a graceful reload. This is my hot-fix backup plan for situations where DNS-01 via our acme-dns instance isn't a timely option. The big draw for me on DNS-01 is that it is decoupled from active services and we can host a dedicated acme-dns instance.
While most of the people in this thread personally don't encounter issues stemming from this because of expertise in these configurations, most end-users are relatively inexperienced and encounter variations of this pattern that result in one or all websites going offline. DNS-01 is rather advanced as it requires a secondary system, most vendors do not offer granular permissions making it a security risk, and the current best-practice setups require a dedicated authorization namespace and a delegation system. There is simply a strong need in the ecosystem for an ACME challenge that is decoupled from Port 80 and other active services, can run via Certbot standalone, and requires a minimum setup/configuration.
I can see that, if we could opt to run http challenges on any low port it would certainly be beneficial. So how do we get the ball rolling for a new challenge type (http-02)?
I imagine the challenge submission part would require an updated payload to specify your port of choice (earlier parts of the acme workflow don't really present an opportunity to specify your port preference). Are there any specific reasons why low ports have previously been dismissed for use with http challenges?