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?
1 Like
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.
http-01 is always over port 80. As webroot is http-01, it’s over port 80, always.
1 Like
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.
1 Like
Let me show you a case why using other external port is essential.
In China, ISP for home users usually block 80, 8080 and 443 due to some gov policies.
So we can only host our website on other ports.
The only solution, I think, is to use VPS as a reverse proxy, which seems stupid and it’s wasting resources.
I’m now using StartSSL and really willing to switch to LE if it is possible.
Hi, i think you will need to wait for dns-01 as challenge method.
Sadly there is no option for email verification because they say that this is
not ideal for automatic verification. Even if this is possible with the correct
autoresponder.
2 Likes
No it doesn't weaken anything i think, usually you are able to bind to any port <1024 with the same rights needed for 80 and 443.
For some cases it's a very good Solution, but you still have to add a DNS record for every Domain. If you do not run your own DNS Server this is often a manual task. Does this record even stay the same over time?
Why not simply skip this step and connect directly to the desired port (<1024)? What if you run something on 80/443 which is not that configurable than your usual apache/nginx/whatever? Ah i know stop the service for some time is such a great idea (not).
80/443 blocked by some firewall you do not (directly) control may also be valid, some "web hipsters" may forget this but not everything which uses TLS is a webserver.
Having 80/443 blocked maybe often a bit awkward but I don't think it is a awkward corner case to not wanting to stop or reconfigure some unrelated service just to request a certificate. Could you elaborate on how this would compromise security? On this level you could even argue to exclude 80/443 because many web server configurations out there are fairly easy to compromise because of insecure PHP scripts or similar compared to other usual privileged services.
In the long run the nicest solution would be to have a dedicated port assigned for ACME.
In my case, port 80 is blocked, but 443 is not. unable to get webroot DV to work. Please help.
If port 80 is completely blocked, you can’t use webroot authentication. Port 80 is a requirement. Usually, you could use a redirect, but that’s not possible if port 80 is completely blocked.
You can use tls-sni-01 (or dns-01 once it lands in production) if your port 80 is unusable. This could be done with the apache or standalone plugin (using --standalone-supported-challenges tls-sni-01).
I use py27-letsencrypt under FreeBSD. Webroot is the only option for this port.
I can’t think of a solution that would work with those constraints at the moment. Once dns-01 lands in production, you can solve the challenge via DNS. All alternative clients I’m aware of either don’t support BSD or don’t support tls-sni-01.
Making http-01-based verification available on port 443 would make the challenge verification vulnerable to the issue described here, so that’s probably not going to change.
My server currently listens on port 8021 instead of 80 and 443 with a self-signed certificate. I want to replace it with a Letsencrypt cert to get rid of the annoying alert.
Being on a non-standard port I’m guessing this server is used by only a defined group of people. So if all you need to do is eliminate the certificate alert, you can just place either the self-signed certificate itself, or the CA for the self-signed certificate in the “Trusted Root Certification Authorities (CA)” store on each client that uses the site.
Self-signed doesn’t mean you have to suffer through certificate alerts.