Support for ports other than 80 and 443

That's not necessary. The CA server will follow redirects (even to https://) and will happily ignore HSTS. As long as you deliver the challenge token at the end of your redirect chain, you're good to go.

The other alternative would be DNS-based validation.

2 Likes

Will it ignore the invalid certificate that I have running on port 443?

Yep! The initial request is HTTP anyway, so there’s no reason to be concerned about MitM for the follow-up connection. The CA server will happily accept self-signed or expired certificates for http-01.

1 Like

+1 to add the option to use a challenge in a port other than 80 and 443.

IMO this would be the ideal solution for servers that are not serving static content whatsoever: run the standalone server in a different port, not interfering with either http or https traffic.

A parametrized port for the challenge to be executed would be the best, but a fixed, usually unused port would also work for me (such as port 12 or 40 as per https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers).

@mehaase: Had a similar problem, this was my solution (I run an nginx proxy in front of my app server by default, don’t know how feasable for you):

server {    
    listen 80;
    server_name  app.example.com;        
    root /var/www;    
    try_files $uri =410;    
    error_page 410 =307 https://$host$uri;
}
server {
    listen 443 ssl;
    server_name  app.example.com;            
    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;        

    //rest of config...
}

`
My /var/www dir is empty except while running the letsencrypt client in webroot mode, and all traffic is successfully redirected to https (you could add HSTS headers if appropriate).

This config does not works when you need to support legacy HTTP traffic (in that case, you still need to take down your app, execute LE client then bring it back up).

Joined to say +1 for allowing clients to use privileged ports other than 80 and 443 to complete the domain validation using HTTP. I do not understand why allowing the validation to take place using, say, port 444 results in a less trustworthy certificate than a validation using port 443.

As a systems integrator/consultant, this would be much preferred to either 1. altering the configuration of an already-customized HTTP server that I did not build and don’t want to break, or 2. stopping a production system to free up the port for a minute. As others have said, webroot validation doesn’t work for a server that does not serve content from a folder (e.g. WSGI).

That aside, to those driving and contributing to this project: thank you so much for your service to build a more secure and surveillance-resistant world. :slight_smile:

Port 444 is not typically a port that serves websites. It is conceivable, for example, that your network security team might be willing to add a firewall rule allowing you to listen on a privileged port other than 80/443 for some service. They probably won't suspect that this would also give you the means to acquire a certificate for their domain. For use-cases where existing web server configuration cannot be modified or port 80/443 cannot be used, there's still DNS-01.

As an aside, the CA/B Forum is currently working on updating the rules for domain validation (still a WIP). They have defined a list of ports that are acceptable for this purpose:

Authorized Port: One of the following ports: 80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

ACME/Let's Encrypt would have to stick to those once those new rules pass the ballot vote. I haven't seen any discussion about adding the last three to ACME on the WG mailing list, but I suppose it would be possible/could be brought up if anyone feels like it's a good idea.

1 Like

DNS-01 suffers from a similar Problem: You have to modify DNS entries in an automated way, this is also non trivial to impossible in a lot of setups.

115 would be a nice candidate, weird old protocol nobody uses.

Another possibility that comes to my mind which also tackles the "we did not know you could get a certificate through this port" problem would be to use SRV records in DNS to explicitly point to the verification service, e.g.:

_acme._example.com. 3600 IN SRV 10 0 115 example.com.

this could also be useful when staying with 80/443 to point to a explicit (v)host handling the verification, e.g.:

_acme._example.com. 3600 IN SRV 10 0 80 acme-verification.example.com.

1 Like

I didn’t notice port 115 on that list when it went to CA/B public. That’s actually pretty funny. Do the people who proposed this list know what Simple FTP (which is the thing the IETF gave well-known port 115) actually is? Because it sure ain’t Secure FTP (aka SFTP) of any kind.

I know the CA/B hasn’t had the best luck in the world at actually writing what they meant, but if their goal here wasn’t to popularise an obscure insecure file transfer protocol from the IETF’s backlog of “interesting but why would I want this?” legacy standards they should cut that from the list.

That doesn't strike me as a bad idea. I suppose it removes the complexity that comes with having to push DNS records dynamically while being about as secure as HTTP-01 or TLS-SNI-01. I guess the question is whether the IETF thinks that the added complexity of another challenge type would be worth the tradeoff in order to support what is more or less an edge case. Maybe suggest it on the ACME WG mailing list and see what kind of feedback it gets?

Yeah, I'm not entirely sure what motivated the Validation WG to include that port. 80 and 443 makes sense, I can understand SSH as control over that usually indicates full server control, and I guess even SMTP is okay, but 115 seems very odd in that list. I'll have to dig around on the mailing list and see if there was any public discussion that lead to this list.

It would be roughly equivalent to following HTTP redirects which is done already with HTTP-01 (and i don't think there is any restriction on host or port there, or is it?).

Does it need to be another challenge type instead of an addition to HTTP-01 or TLS-SNI-01 on how to lookup the host:port to contact from DNS?

Maybe they confused it with the SSH File Transfer Protocol. :wink:

I seem to recall that boulder limits the redirect to 80/443 (not sure if programmatically or through firewall rules). Not sure, though.

Good point, that could work.

it can't be done without compromising security.

If someone starts the software on port 81 or 8080 (non-root port, any user can use the port

Bull. Ports under 1024 require root privileges to open. If the user is already root on a shared box, forget issuing certificates--he can just take existing certificates. Or data. Or wipe the box. Or stop nginx, do the port-based authentication method, then start nginx again.

The argument that using an alternate port under 1024 is insecure is nonsense.

1 Like

well support for other ports may come in the future but on a very limited set, because the CABforum actually defined usable ports

That is just complete idiocy, that i cant use ports beyond 80 and 443.
Why there is no option to validate on the other port?
That is just going wrong with every aspect of this project, that is (i hope) trying to bring simplicity into the certificate issuing/reissuing.
Does it compromise security in some way, or i dunno, is it so hard to implement? Why am i forced to have an SSL connection on specific port? That is just wrong.

1 Like

Please be more kind...

You can use DNS validation too.

And if you already have a webserver listenning to these ports, certbot just need to have a directory that can accept files for the well-known/acme-challenge/ path. If you don't have a webserver running on these ports, certbot can use them to validate the challenge by running it's own webserver, you don't have to run your own.

You are not. Once issued, you can use the certificate for any port.

1 Like

Thanks for your considerations.

DNS validation usually only complicating things. TTL and stuff like that.
Usually, when i need to use other than 80 or 443 port, it means i have unable to use native ports in any of suggested scenarios. There are a lot of cases even in this thread, and many other threads.(here for ex.)
They can be provider-blocked, i may have a need to use nat to forward a port to specific host, there are tons of usage scenarios, and based on number of questions around the net, it’s a needed feature.
Why the hell it haven’t been implemented yet?

1 Like

Make up your mind. Do you want your esoteric edge case to work or do you want the easy way? If you can't host on 80/443 to the world, why would you need a cert anyway?

Get proper connectivity or use DNS-01.

Yes.

As has been pointed out before in this thread, the Baseline Requirements limit the set of ports that can be used for domain validation by publicly-trusted CAs (see the definition of “Authorized Port”). If you believe that control over arbitrary ports should be sufficient, your first step would have to be to convince the CA/B Forum to change that rule, at which point CAs could start supporting other ports (though there would be no mandate to do so).

The CA/B Forum had good reasons for limiting the port list. You can probably explore the thinking in-depth if you want to spend some time reading through the Validation WG mail archives.

With dns-01, solutions like acme-dns, redirect-based approaches for http-01 and SNI-based routing for tls-sni-01 I think we have sufficient options for all use-cases.

2 Likes

Aww, Flash, so cute. Maybe try again?