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
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”.
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
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
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.
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. 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
There are also other SSL Servers that can solve the ServerNameInformation challenge:
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.
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.
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.
You can use the standalone method and specify the particular port you wish to validate over. You might also be able to use the webroot method, but I’m not sure if you can specify the port on that. Someone more familiar with the reference client may know.
webroot AFAIK is off port 80
Yeah, I just checked and webroot doesn’t offer a different port option. Manual looks like it does, though.
Well seriously, if you want to host HTTP(S) but your ISP blocks 80 and 443, then maybe what you’re doing isn’t the best idea in the first place. Get a net-neutral ISP or host on professional infrastructure if you can’t do that from your home.
I see no reason for the CA to bend itself to every awkward corner-case of every weird endeavour someone might be doing, always compromising security a little bit in the process.
What’s next? A special process for people behind carrier-grade NAT that want to host websites off their smartphones?
he might want to host something different from http/s or he wants his hown https’ed cloud where he can use any port he wants…
Then it should be no problem to choose any other CA whose verification process doesn’t need to be weakened in order to use it. It’s not like Let’s Encrypt suddenly made all other CAs disappear.
As soon as LE supports DNS verification, maybe that’s a thing that helps here, although I can see it already: “What if I run my DNS on some other port than 53?”
If your infrastructure is so crippled you can’t even host on port 80, maybe even more band-aids and kludges isn’t the solution. I certainly wouldn’t support it. It just takes stress away from these fascist ISPs.
Edit: And no, specifically blocking 80 or 443 is certainly not normal. If you pretend it is and simply put up with it without resistance, you’re part of the problem.
Updating cert but server is not in default port 80
http-01 is always over port 80. As webroot is
http-01, it’s over port 80, always.
well the verification is weak in the first place and any >1024 port will suffice because all of those need more rights on the server.
also DNS or email verification (which is quite a bit more secure especially when the domain has DNSSec) migitates the whole problem
I don’t understand; it sounds like you’re saying this issue should be closed because the client already supports ports other than 80 and 443.
It’s possible to tell the client to bind to a different port (using
--http-01-port), but validation from the CA server still happens on port 80/443. This was added for users who don’t want to stop their regular web servers on port 80/443, but rather add a reverse proxy pointing to the client’s web server. It won’t help if you can’t run an external service on 80/443.
DNS-based challenges (hopefully coming soon) will offer an alternative for users with this limitation. That should cover almost all use-cases.