Support for ports other than 80 and 443

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?

Odd. It was just raw a link to https://giphy.com/search/eye-roll. Instead of showing the url or the image in the og:url (which is an animated gif) the forum software is upgrading it to a flash embed.

You should have seen this non-flash image: https://media.giphy.com/media/3oAt2dA6LxMkRrGc0g/giphy.gif

1 Like

So, it has some roots after all.
Thanks guyz.
Especially pfg.

But thatā€™s still really strange restriction, if you ask me.
Thatā€™s like the first occasion for me, to be unable to use open source tool the way I want it, not taking into account restrictions by technical means, for my over 15 years work experience in IT. Guess things are starting to change even in good old open-source world.

You can interpret the CA/B Forum validation restrictions as ā€œtechnicalā€ in the sense that theyā€™re thinking about protocol semantics. In that sense, they might be analogous to the way that you can run an SMTP listener on a port other than 25, but you canā€™t receive mail from other hosts through that listener unless theyā€™ve been manually configured to use the other port.

Itā€™s also a protocol semantics-related rule in the way that rsh and rlogin trusting data in connections using port numbers <1024 was: itā€™s a way of trying to confirm that the connection was originated by a sysadmin or by someone with the authority of a sysadmin. In this context I think thereā€™s also a further concern about protocol-in-protocol and chosen-protocol attacks.

A reason to be concerned about this is that there are a lot of shared hosting systems on the Internet where many customers have shell access, and each customer hosts an independent web site. On these systems, customers arenā€™t authorized to obtain certificates for other customersā€™ domains, even though the DNS records for each domain points to the same shared server. So itā€™s important that CAs have some means to know which certificate requests are authorized and which arenā€™t, when both genuine and spurious requests could originate from the same IP address. In the shared server setting, port and protocol restrictions help achieve that goal.

4 Likes

In general, I agree with you, though it's not common practice among web applications to listen on ports 80 and 443, for example jira, jboss and others. Sure, you can reconfigure, and remap, but that's the default. I'm just saying that's not the rule of thumb in case of web applications, as it is in SMTP.

Are they using virtualhosts to separate them on the same 443 port? Or are they using different ports for each? In the first case, CA's wont be able to tell wich of them is authorised anyway, cause reverse dns will show all of them. Second will be unable to issue. Seems I didnt really followed your line of thought.

Yes, they're using different virtual hosts on the same port. In this case, they can't individually pass TLS-01 challenges (only the sysadmin can do that for them), while they can pass HTTP-01 challenges (because they control the respective web roots of their individual virtual hosts). Let's Encrypt and ACME don't use reverse DNS for any purpose. You have to say the names that you want a certificate for, and then have to be able to make changes to authenticate your control over those names, using the forward DNS resolution.

2 Likes

In the above scenairio hosting provider should restrict incoming connections to this host form the internet to ports 80 and 443, and dont allow users to edit vhosts confiruration. That's like the end to this security concern. They wont be able to launch another copy of apache on a different port and get a cert. If that's what you mean.
Yes, most likely customers want ssh, ftp and other services to be availiable, but thats hardly a problem of CAs. That's a hosting provider's problem, and their security concern. Especially, if they're using one entry point. There are a lot of solutions for traffic categorisation to implement these restrictions.

Right, they specifically won't be able to do this because of the CA/B Forum rule that limits DV validations to ports 80 and 443. If it weren't for that rule, the customers could potentially launch some software on a different port to pass validation for other customers' domain names.

1 Like

You do realize, that there is a gap between what you "believe in", and security in terms of IT?
Yes that's quite easy, deploy ubuntu, install apache, assign real IP, install certbot, run command - profit.
But this scenario is only viable for product marketing, there are usually other complications and resource management restrictions in deploying applications in an existing infrastructure.
But as an administrator, you can always try to fit through the gaps. If someone won't push on you stupid restrictions in an open source software.

This is pointless. There is nothing more secure in port restrictions. It's just one group of people, trying to fix other people mistakes in securing their servers.

It seems to me that if you really ā€œcontrol the whole serverā€ it is very easy to pass the ACME challenges.

If a person says to me that they ā€œcontrol the whole houseā€ but insists they will only prove this by putting a gnome in the front garden, saying thatā€™s part of the house and itā€™s stupid to think requiring a change inside the house proves more, well, I donā€™t believe them.

With 15 years of IT experience you should have no problem deploying a DNS-01 setup. Otherwise, take it to the CA/B forum and convince them their restrictions are stupid and that they should lift them in order to accomodate people who donā€™t even have proper 80/443 connectivity. The bickering about minute details isnā€™t helping here. No one here can do anything about it because LE likes to play by the rules and keep its inclusion in major browsers.

Well, taking into account itā€™s now hottest unresolved feature request topic here, and Letā€™s Encrypt is also gets a lot of hype, i hope itā€™ll move things a bit.

Thanks.

BTW, does the renew cert trigger host re-check? For ex., if ill open 443 and get a cert using TLS-SNI-01, am i required to keep this port open when renewing?

Renewals generally require solving a new challenge, unless youā€™re solved a challenge for the domain within the last 7 days or so, in which case you may reuse an existing challenge (or more accurately, an authorization). The 7 day period might be lowered in the future, so itā€™s best to assume each issuance requires solving a new challenge.

1 Like

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.