# Any way I can get certificates for my scenario?

**URL:** <https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526>\
**Category:** Issuance Tech\
**Created:** [June 3, 2016, 12:59am UTC](https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526 "2016-06-03T00:59:17Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![LFCavalcanti](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@LFCavalcanti](https://community.letsencrypt.org/u/LFCavalcanti)\
**Post date:** [June 3, 2016, 12:59am UTC](https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526/1 "2016-06-03T00:59:18Z")

</div>

HI everyone!

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](https://rocket.chat/), [GLPI](http://glpi-project.org/) and [OwnCloud](https://owncloud.org/). 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.

---

<div class="post-metadata">

**Author:** ![pfg](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/pfg/32/1924_2.png) [@pfg](https://community.letsencrypt.org/u/pfg)\
**Post date:** [June 3, 2016, 2:22am UTC](https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526/2 "2016-06-03T02:22:51Z")

</div>

> [@LFCavalcanti](#):
>
> 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.

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](https://github.com/certbot/certbot/wiki/Links#bash) or [lego](https://github.com/xenolf/lego). It's not quite finished in certbot, but hopefully coming soon.

---

<div class="post-metadata">

**Author:** ![LFCavalcanti](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@LFCavalcanti](https://community.letsencrypt.org/u/LFCavalcanti)\
**Post date:** [June 10, 2016, 2:12pm UTC](https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526/3 "2016-06-10T14:12:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pfg](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/pfg/32/1924_2.png) [@pfg](https://community.letsencrypt.org/u/pfg)\
**Post date:** [June 10, 2016, 3:00pm UTC](https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526/4 "2016-06-10T15:00:43Z")

</div>

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](https://www.ietf.org/mailman/listinfo/acme), which is where the ACME working group is discussing changes to the current ACME draft that Let’s Encrypt implements.

---

<div class="post-metadata">

**Author:** ![LFCavalcanti](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@LFCavalcanti](https://community.letsencrypt.org/u/LFCavalcanti)\
**Post date:** [June 10, 2016, 6:01pm UTC](https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526/5 "2016-06-10T18:01:00Z")

</div>

I am an IT Manager plus Network Administrator.

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.

---

<div class="post-metadata">

**Author:** ![leader](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/leader/32/7569_2.png) [@leader](https://community.letsencrypt.org/u/leader)\
**Post date:** [June 10, 2016, 6:16pm UTC](https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526/6 "2016-06-10T18:16:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pfg](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/pfg/32/1924_2.png) [@pfg](https://community.letsencrypt.org/u/pfg)\
**Post date:** [June 10, 2016, 6:29pm UTC](https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526/7 "2016-06-10T18:29:05Z")

</div>

> [@LFCavalcanti](#):
>
> 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.

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.

> [@LFCavalcanti](#):
>
> 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.

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.

> [@LFCavalcanti](#):
>
> 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.

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.

> [@LFCavalcanti](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [July 10, 2016, 6:29pm UTC](https://community.letsencrypt.org/t/any-way-i-can-get-certificates-for-my-scenario/16526/8 "2016-07-10T18:29:06Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.