Support for ports other than 80 and 443

People have asked about this a lot, but this feature would require a rule change from the CA/Browser Forum. It's not simply a matter of patching Boulder and Certbot with a --port-number option or something. Let's Encrypt could fail our audit if we allowed the use of an unapproved DV verification method, as @pfg mentioned earlier in the thread in regard to the Baseline Requirements.

Authorized Port: One of the following ports: 80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh). [...]
Confirming the Applicant’s control over the requested FQDN by confirming one of the following [...] on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port [... or ...]
by confirming the presence of a Random Value within a Certificate on the Authorization Domain Name which is accessible by the CA via TLS over an Authorized Port.

Supporting this feature would require a consensus elsewhere, not just here. These policies exist because of debates about how to manage the risk of certificate misissuance due to different kinds of impersonation attacks. As I suggested above, this is a kind of technical consideration because people concluded that the ability to make some kinds of changes proves some kinds of control more convincingly, and the main point of a certificate is that the CA was convinced that it was issued to a proper recipient, not an improper one.

Under the existing Baseline Requirements, the addition of ACME challenges that use port 25, 115, or 22 could be considered with no policy change [edit: although seemingly if they use an unencrypted protocol, it has to be HTTP, while if they use an encrypted protocol, it has to be TLS, both of which create some challenges for practical applications of 25 or 22 right now], but we'd still then say that these need to be discussed in the ACME working group (and maybe they are already being discussed there) in order to make it clear exactly what the proof requested by the CA should be.

A slightly terser answer than @pfg's accurate answer is "Yes". The DNS-01 method exists in part for people who dislike the idea of allowing these inbound TCP connections.

1 Like

Completely agree this is plain stupid any port above 1024 should be allowed you should not make assumptions about customers setups and what their security team expects to happen or not. The only assumption should be that you know and understand what are you doing.

I do know that on cPanel you don’t care for the ports, SSL is for the entire name

Not quite accurate.

cPanel AutoSSL works by validating control of the domain over port 80 or 443, only. With the Comodo (default) provider, this happens on the /.well-known/pki-validation/ path, and the Let's Encrypt provider uses /.well-known/acme-challenge/, obviously.

The domain validation characteristics are exactly the same. If the domain is not accessible over 80 or 443, then AutoSSL doesn't work.

As mentioned further up the thread, this a restriction of the CA/B Baseline Requirements that affects all certificate authorities, rather than a choice by Let's Encrypt.

Once you have the certificate, you can install it to whatever port you like (:2083, :2087, :587, :465 etc), but it's beside the point.

1 Like

You can do anything you want on a private system where you control the landscape and push your own trusted certificates out. In fact, you should do that. You can even run your own ACME server if regular rollover is critical. Let's Encrypt and other public CAs, though, are here to serve the public; not every internal need is intended to be addressed by a certified public CA.

Wrong again, and you don’t understand what are we talking about here. This should be a project providing certificates for the masses, meaning everyone, NOT to make the life of the ISP’s easier (just a reference to some previous comments how this will affect them). Making it possible to validate the client on any non reserved port can cause no harm, every ISP or corporate network would have those ports closed (for this purpose) anyway and people would be still forced to use 80 and 443 for the challenge. In this case there would be a router/firewall/proxy as an entry point correctly distributing the incoming challenges to the right end points. They would be doing all this on behalf of the customers/employees anyway so no issues here, they are still in control.

Now imagine you are behind a small office firewall/router which has ports 80 and 443 already used (for a company web server or phone system UI or whatever) and does not have the capacity mentioned above. And game over, you can run your Let’s Encrypt client (server) on your station on any port you want but the challenge will never reach back. This is a very common scenario, are you saying that all this people should install additional infrastructure just to test LE staging certificates?

1 Like

There's no need to write venomous posts. If you feel so strongly about it, you can petition the CA/Browser forum directly, since a ballot there is the only way to effect the changes you want.

Making it possible to validate the client on any non reserved port can cause no harm

The 0-1024 port reservation not universal across platforms (check Windows, you do not require any privilege to begin listening on those).

If unreserved ports are permitted as domain control validation methods, I guarantee there would be an immediate influx of mis-issued certificates.

To illustrate only one case, cPanel, by default, has a TCP range open for use by FTP connections:

ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpts:49152:65534 ctstate NEW

Unprivileged users can listen on these ports from any userland application, and instantly get authorization to issue certificates for any tenant hostname (including the primary hostname of the server/hosting company).

There are hundreds of thousands of cPanel servers on the internet today, serving tens of millions of domains (the cPanel AutoSSL CA has issued ~30M certificates in a year or two).

It is definitely not the case that this change would "cause no harm". The issue is complex.

1 Like

Really? Stating a fact counts as venomous these days? I agree though the preassure needs to be applied to the relevant body for the needed changes to get accepted.

No there won't, you still need to be in controll of the dns for the domain you require certificate for otherwise the challenge will never reach back.

So what? All they gonna achive is get http request sent to an ftp server ports that you can reject based on the protocol. Don't forget, the ISP is still in control. And since when the ISP's allow users to run Let's Encrypt
server on their own via cPanel or install any binary on the server hosting their web application? I would imagine every LE cert request is made by the ISP on behalf of the customers so the whole process is under ISP's control, on separate LE dedicated servers I would imagine, and customer never gets to decide about port or protocol involved. So how are the customers possibly going to abuse the port range 49152:65534 you gave as an example?

No its not it is pretty simple actually.

You don't have to install a binary, a shell script can suffice. There's a large number of people doing this on GoDaddy shared hosting right now.

This is also not an accurate statement. In that case of shared hosting, it's entirely possible for multiple domains to point to a single IP. If you were also able to control the port the challenge is being issued over, you could listen on that (unused) port and issue certificates for any domain on that shared IP. Now, granted, you're not wrong than a hosting provider would ideally prevent this, but the unfortunate reality is that's not always the case. In general, the risk of mass mis-issuance is going to supercede the benefits for non-standard use cases.

Besides, in your common scenario, there are several solutions to allow issuance (most using SNI, and of course there are always DNS options.)

Please don't mention GoDaddy when talking about security, really. Anyway, an ISP can easily block on the edge of their network any requests going to LE and not coming from dedicated servers only.

Possible, but in that case it would be a bad design and again no one sane would allow that if they care about their business. That said mis-issuance of certificates is happening now in the current CA world, remember this? Google takes Symantec to the woodshed for mis-issuing 30,000 HTTPS certs [updated] | Ars Technica

Not possible, please read my comment again. It is simple port forwarding on a plain old router there isn't anything else involved that can make a routing decision based on SNI or what ever else.

You’re still missing the point. The fact that this is the reality of the internet is part of why the CABF maintains the limited ports requirement. Adding one more thing for a hosting provider to check deteriorates assurance.

For the second post, I’m not referring to the router. Most routers can’t route based on SNI. I’m talking about what’s behind the router. Again, there are numerous ways to handle this for a multitude of scenarios. Perhaps if you made a help thread describing your setup and the challenges you’re facing, the community could help you through productively solving this problem.

2 Likes

I don't think so. Also your example is pretty theoretical, if you are not in control of what your customers are allowed to run on your servers then you have much bigger security issue. I'm sure a simple security auditing will (and should) put that kind of company out of business. The thing is that low grade companies like that have been slipping through the cracks for long time when security is in question.

Now the point that you are missing. As a long term Unix and open source user I have enjoyed one very important thing: the freedom of choice! And that is all what this is about. The choice should be there and it should be left to the people to decide to use it or not. If the providers are not happy with that they can keep only ports 80 and 443 for their customers as they do now.

There is nothing behind, ports 80 and 443 are simply forwarded to a box with specific function. And I'm not trying to design anything and I don't need anyone’s help I'm just giving you a very common scenario that is present in many SMB offices. Even more, I don't want to have anything behind, I want to be able to get LE certificate in this case too.

This issue was discussed at great length in the CA/Browser Forum as well as the ACME working group. There are lots of shared hosting providers today that allow users to listen on arbitrary ports of shared servers that answer for many different customers’ domain names. You may think this is improper, but the hosting providers commonly justify it with reference to their understanding of the semantics of well-known port numbers (that is, it means something different to let someone answer traffic for port 443 as opposed to port 25 or port 11111).

The CA/Browser Forum has an explicit list of approved DV validation methods. You can find this list in section 3.2.2.4 of

There are clearly many other things that a subscriber could do or change on a server that in some settings would confirm the subscriber’s control over a domain name, yet the Forum forbids CAs from using other methods by default. For example, if Let’s Encrypt unilaterally started allowing TLS-SNI-01 to port 9876 as a basis for DV issuance, it would put us in breach of the Baseline Requirements and could be a reason for browsers to remove trust from Let’s Encrypt certificates.

Preventing one shared hosting subscriber from being able to get a certificate for another subscriber’s domain name is a very high priority for the Forum. Any significant risk of this possibility is clearly enough reason for them to choose to forbid proposed DV validation methods. This kind of concern even led to technical changes in Let’s Encrypt’s existing validation implementation—it’s why HTTP-01 validation is only available with an initial HTTP connection on port 80, rather than also allowing the option of port 443. This was a result of a discussion showing that a small but significant minority of shared hosting providers might have configurations allowing one customer to get certificates for another customer’s domain if HTTP-01 were permitted on port 443 (because of the default behavior of HTTPS virtual hosts in some configurations). You could make your argument here as well that the hosting providers in question should not have this configuration, but it was already considered an unreasonable risk to take in this situation.

Let’s Encrypt already fought hard to allow three different automated DV validation methods (TLS-SNI-01, HTTP-01, and DNS-01), not just one, because of our recognition that different people in different hosting or firewall environments will be in a position to make best use of different methods. But each method introduces new potential risk of misissuance and has to be affirmatively justified in terms of a security argument about why only the domain owner or someone approved by the domain owner will be able to pass the validation challenge. The existing port restrictions have always been a part of that justification and would continue to be a part of any future discussion in the CA/B Forum about new validation methods.

5 Likes

The "box with a single function" is what is behind the router. This terminology refers to things as you'd see on a network diagram. In this instance, the solution is to either configure said single-function box to proxy requests with specific SNI to another box, or place something in between this box and the router that passes requests to the appropriate other devices. Alternatively you could sync challenges to the outward-facing system during the issuance/renewal process (this can be admittedly tricky, though.)

Of course, there's always DNS challenge types that eliminate the need for Let's Encrypt to even connect to your domain in the first place.

Between the available challenge types, there should be a reasonable method for a vast majority of users to Let's Encrypt certificates. However, when if comes down to it, Let's Encrypt isn't for everyone. In your example, it seems that the systems requesting certificates will never be accessed by the outside world. That being the case, there are circumstances where an internal CA could be advisable.

For the third time, imagine it is a third party box with propitiatory firmware and you can't do anything there. Also read my initial comment, I don't want to (or can't, or don't have the skills to) introduce additional infrastructure just to test single test certificate issuance.

And imagine you are not in control of the DNS server. Or you don't have time to submit forms to the security team and someones DNS admin team and wait for a week just to quickly test staging LE cert issuing.

And again, I understand all about LE and what's involved, I design LE centralized solutions for our infrastructure in Amazon AWS. I'm just pointing to the trouble that some people need to go through just because some providers are not standard complaint and we have to band the rules to accommodate them.

@schoen First to make one thing clear, I am not arguing that you guys are doing anything wrong, you have done a great job. As you explained in another comment before the problem is with the CA/Browser Forum which very existence in the first place I find being a joke. It is like giving someone the power to be the prosecutor and the judge in the same time. Take DANE for example: DNS-based Authentication of Named Entities - Wikipedia. This would mean people can be their own self-signed CA's and issue certificates that the browsers can verify via the CA obtained during DNS resolution for the domain. Now CA's would not like this to become a standard, accepting this would mean voting them self’s out of large chunk of their (blood sucking) business. I'm aware that not every one can run their own PKI but many of us can.

And the problem you pointed here:

just makes the whole thing about these Forum hypocritical. They are ready to put limitations on new technologies because of non compliant providers instead of making everyone play by the rules. It might because they don't have the power needed for this which brings me to my point: these rules need to be designed and enforced by an (CA's and Browsers) independent body (if it doesn't already exist) that can deal with all this noncompliance jungle that's been allowed to grow for decades. And the CA/Browser Forum should be told what to do avoiding the danger of someone/something potentially being held hostage of their own interests.

@igoratencompass, consider the following example:

There is a NAT box (router) which has 192.0.2.42 and 2001:db8:1ef9:8325:fad2:98b2:521c:8e45 addresses assigned. For users convenience, there is a DNS record which points to these addresses - let’s assume it is users.example.com. Each user has its own port range at their disposal (say, 50 port numbers), which is redirected to their individual virtual machines (isolated from each other). They are free to use them in any way they like (as you said, you enjoy the freedom of choice). Let’s assume that CAs are allowed to perform validation using port number arbitrarily chosen by user, as you suggest.

How would you prevent user from obtaining certificate for users.example.com?

How would you validate - in an automated way - that service listening at given port number is allowed to obtain certificate for domain pointing to these addresses?

Do you believe it should be responsibility of network administrator or responsibility of certification authority?

I think the productive discussion that can happen around this topic has already occurred & I’m going to close this thread. Follow-up discussion should be handled in a new topic.

Thanks folks!

1 Like