Support for ports other than 80 and 443

Feature Requests
1

Hello all

I’m very excited to be part of the Let’s Encrypt beta. It’s a great service so I’d like to start by saying, “Thanks!” That said…

I’ve found the DV process to be rather inconvenient (especially when compared to sslmate.com’s process). The biggest problem is the client’s need for ports 80 and 443 (forcing me to stop nginx when requesting/renewing certificates). I understand the desire to ensure the request is coming from the domain’s owner but surely any port < 1024 would suffice. I’m also not keen on messing about with my nginx configuration just to support the webroot method. The LE client should do one thing and do it well; verify the domain and download the certs.

I’d like to see the client become a service running in the background on it’s own port(s) and simply requesting/renewing certificates as required. I’d then use incron or similar to reload my various server configurations when the cert files change. Better yet, some git-style hook scripts for various LE client events.

Thanks

8 Likes
2

use webroot or manual then you just put a file in your web root ( the folder that is the main folder of your internet domain) and you are good to go.

3

@My1 Note that LE script requires that Content-Type for its verification files be exactly “text/plain”; however, in real-life cases, it might look like, say, “text/plain; charset=UTF-8”.

In current state, LE script might need to ether change the Web server configuration (even if within separate directory and in separate .htaccess/whatever else used to tweak site settings). The best solution would be just to place file without any further configuring.

JMNSHO.

4

exactly what I think too.

if you accidentially post an image or whatever the size will already tell no need for type check.

5

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) on a shared server. He/she can validate all domains point to that server since the A records points to IP address, and get certificate to do MITM attack.

Instead the web server can be configured to forward (proxy) /.well-known requests to 127.0.0.1:8080 and if LE client can listen on 8080, the CA software can still make authorisation request over 80 port without compromising security.

6

that’s why maybe DNS is better I mean if you dont need to change it each renewal you just have to set up a record once and that’s it.

7

It’s a security compromise too.

If you wouldn’t need any change in DNS records to renew the certificate. Anyone can instantly renew your certificate after you get the first certificate, and the one can use the certificate to make MITM attack.

8

well not exactly a DNS record that could be linked to your LE account key, pretty much similar to webroot then it could work, maybe also allow email auth (with the admin mails and/or the whois mail) for manual mode.

9

No, you would still have to sign the renewal request with your private account key.

10

@kelunik @My1 yeah, that would work.

12

I am for extra ports as well i addition to DNS verification because when you have 2 PCs sharing the same IP (home internet) one is your webserver and one your LE client you cna say redirect 81 or whatever to my raspi or whereever LE runs on for the verification

1 Like
13

I am also very much in favor of this feature, anything <1024 should be as good as 80 and 443. Would be a great simplification of the process to not having to involve an already running web server. A LE client could simply default to bind to some currently unused port inside this range while performing verification (maybe even prefer currently unassigned ones or ones assigned to some obscure protocol no one uses nowadays to minimize possible interference) and operate completely standalone.

That i think would be the closest you can get to install the client and it “just works”.

14

that's exact what i use webroot authentication for - I've fully automated the Letsencrypt webroot process including auto renewal for my Nginx based LEMP stack now Letsencrypt Webroot Authentication Tested on Beta invited/whitelisted domain - #5 by eva2000 :slight_smile:

15

well if I could get my raspi to get the correct webrrot for each of my domains and push the files to my win PC fine, but if I can get it running through a different port that can be forwarded to my raspi in one step I’ll gladly do that

1 Like
16

I’m in the same situation of @sdc395 : being forced to close all applications that use the 80 and 443 ports is really annoying (in my case nginx and OpenVPN).

Also, I prefer not to use the webroot method because I have a lot of subdomains to authenticate and some of them are not even used in nginx, but for a mail server.

Please use a random unused port < 1024 , it will make the standalone process better.

17

if you use nginx you can also setup a default server to handle LE SAN SSL multi-domains outlined at Using the webroot domain verification method - #7 by Leliana. I did this for testing at https://community.centminmod.com/posts/20018/ as well. So you could do it this way for mail server and none http/https facing server subdomains etc

18

There are also other SSL Servers that can solve the ServerNameInformation challenge:

  • SMTP(S)
  • IMAP(S)
  • POP3(S)
    Realy cool would it then the boulder server would support these protocols including STARTTLS but i think this is an feature that will be on the long term list.
19

@sdc395 did you see that you can specify port?

20

Yes, thank you, but this isn’t really a solution. I still have to “integrate” the LE client with my web server config (the proxy settings). I’ve settled for the webroot approach for now but I’m still keen on the idea of the LE client being truly standalone and playing nicely with other services.

21

I haven’t seen anyone mention this issue yet, which is, what if my server is running from a residential address where the ISP blocks port 443 and 80. This is the case for me.

4 Likes