So, I work for an IT Service Provider. I’ll make clear from the get go, sadly we are small and don’t have much options when investments are concerned, I wish we had better conditions but I’m trying to do the best I can for the team I’m managing.
Our main Web Site is hosted on a company called Locaweb, we have a shared host plan, and they don’t support the installation of Let’s Encrypt clients in those conditions.
I need the certificates for 3 services we will run here: Rocket Chat, GLPI and OwnCloud. As I stated before, since the budget is well, non existent, we will host them locally.
The problem is, we have issues to get both ports 80 and 443 open and none of the Let’s Encrypt clients I tried, be it for Nginx, Apache or even the one of the Windows clients don’t allow me to use the port those services are running to validate the domain ownership.
I’ve read something like 10 threads and found ZERO ways to do it other than having a webserver running on the IP the Host A resolves to on port 80 so the client writes the validation file.
Some people claim this is a security concern, what to me is a misconception, and more a dogma than a security measure really. If you are requesting the validation from a valid DNS pointer, the port doing the verification is irrelevant and I’m sure there’s a awful lot of people who are in the same conditions I am.
So I ask, is there any way?
DISCLAIMER: Sorry if this sounds like whinning but frustration some times becomes overwhelming. Let’s Encrypt is just so great I can’t really complain.
The security concern here is that CAs have to validate domain ownership. In order to do that in a way that prevents anyone behind the IP address of your domain from getting a valid, publicly-trusted certificate, this validation has to be performed on a port that is, more or less, privileged. Port 80 and 443 are both default ports for websites, so if your network allows you to listen on those ports, that is sufficient to demonstrate that you are authorized to get a certificate for the domain - you essentially have full control over the website content anyway. If Let's Encrypt would allow you to use any port, network teams would have to scramble and lock down all their incoming firewall rules unless all operators of services behind any open port are authorized to get valid certificates.
To answer your other question, you can use the DNS-01 challenge type, which verifies your domain ownership using a TXT record with a random challenge token. This doesn't require any open ports, but you'll have to find a way to automatically update DNS records for your domain (or at least do so manually every 3 months). There's a number of clients that support this, like the bash clients or lego. It's not quite finished in certbot, but hopefully coming soon.
This was addressed before, regarding the port numbers being “root only”.
They could accept requests from port 81 then, still under Root Authority and solve the problems for those of us who need to host server in non standard ports.
This isn’t about whether root is able to bind to the port (i.e. permitting any port < 1024), but rather about firewall policies in general.
It’s an application of the rule of least surprise. A network administrator might add a firewall rule allowing the mail team to listen on port 143 (IMAP). It would be surprising, and therefore a possible violation of their security policies, if that would suddenly allow the mail team to acquire a certificate for their domain name. Misissuance is one of the worst things that can happen to a CA, and it makes sense to be conservative here. If the same network team allows someone to listen on port 80 or 443, however, that’s fair game as 1) whoever listens on that port can already change website content, so is essentially “in control”, and 2) it is similar to how CAs have been determining ownership in the past 5-10 years, so it should not surprise anyone.
I see little reason to change this behaviour given that there are challenge types that do not suffer from this limitation at all. You are, of course, free to raise your concerns on the ACME mailing list, which is where the ACME working group is discussing changes to the current ACME draft that Let’s Encrypt implements.
The concept that port binding provides security is flawed at it’s core.
I could make a NAT Port-Forward for my server from 80(public) to 54321(Internal) and Outgoing too, the Let’s Encrypt client wouldn’t even know it. This have nothing to do with security, this is a mentality choice, one that limits who can use Let’s Encrypt.
About the DNS Challenge, I tried my best to find “ease to use” documentation on it… there is nothing than an “average Jhoe” can use at the moment. I did find information, but by the time I got it working was too late.
The Domain Ownership should have been done with e-mail validation at postmaster@domain, with Let’s Encrypt server generating a key for that domain, then the “average Jhoe” would use that key on the client to validate it’s identity and ownership of the domain.
That makes the port use completely irrelevant, plus the validation also should test if the subdomain requesting the certificate matches the DNS pointers for the domain.
I’m truly sorry if this sounds as aggressive, that’s not my intention, this is however a rant and criticism on this design choice that is causing much more trouble for the project than solutions as I suggested above. If this was truly designed for the “average Jhoe”, we shouldn’t require people to dig through mailing lists and Issues on GitHub to understand how a simple certificate request works. Even StarSSL have a easier system to use.
And before someone says I’m just complaining and whinning, this is a criticism on a design choice, you can’t contribute something if you’re limited by the choices of a few. This concept of port binding is so wrongly used here it’s infuriating.
Say that the “limitation” is removed and you could use any port. Who would be picking the port? Probably not LE (since you want a particular port to be checked rather than randomly picked, which might be also taken). Then the client perhaps? But then you have an ability to effectively port-scan other machines by using LE servers - give them FQDN, port and see the response. Doesn’t sound too good, does it?
Don’t get me wrong, you might be thinking of some good use cases, but don’t forget about misuse cases.
Let's say we both work at the same company and I'm the network administrator. I care about security and don't want anyone in my organization to be able to get a certificate for our domains. No one other than me has access to our network devices (router/firewall). How do you get access to port 80/443?
This is not about whether you can forward ports to different ports internally (you obviously can), but whether ACME allows network administrators to secure their networks without waking up one day and noticing that your firewall policy allows misissuance.
Take a look at the clients I linked above, I found their documentation to be reasonably good. I agree that DNS-01 support for certbot should be a high-priority item.
One of the core goals for ACME was to be automated, which is a necessity with short-lived certificates.
Email validation works great for traditional CAs where the process is manual, but it's not a good fit for an automated CA.
I think you're misunderstanding the reasons why the ports were chosen. CAs have to be absolutely certain that a certificate is actually requested by the actual domain owner. They would lose their trust status if they fail to do this. That is why the semantics of the ports that are allowed for this matter, not just whether root can listen on them by default or not. Port 80 and 443 are clearly defined as ports for websites, and being able to change website content is a reasonable way to demonstrate domain ownership. The same cannot be said for every port < 1024.
On a related note, the CA/B Forum, which defines the rules that all public CAs have to follow in order to become trusted, is currently in the process of changing the rules for domain validation. The current draft contains the following section, listing the ports that are considered to be appropriate for domain validation challenges such as HTTP-01:
Authorized Port: *One of the following ports: 80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).
The reason I'm mentioning this is that even if Let's Encrypt/ACME would decide to change their policy to allow any port for HTTP-01, they'd have to revert that change once that section is included in the Baseline Requirements (which is probably going to happen fairly soon).
I suppose it's possible that new challenge types based on the other ports allowed by that language will be introduced in the future, though I haven't seen any discussion on the matter.