Instructions state: “If you get a connection refused or connection timeout, you may have a firewall blocking port 80. tls-sni-01 used port 443, but http-01 uses port 80. Ideally your web server should allow both ports. If that’s not possible, for instance because your ISP blocks port 80, you’ll need to switch to the dns-01 challenge, or use an ACME client that supports tls-alpn-01.”
I upgraded the letsencrypt/certbot client, its version .28. The dry run produces
http:mydomain/.well-known/acme-challenge/GTdHfTxxWak9OzZtqYHajHiJgMeBqWNCxYS6Ceh0YB8:
Timeout during connect (likely firewall problem)
Well, of course it can’t, I block non-SSL traffic, why would anyone allow http?
The confusion stems from the instructions bolded above. “need to switch to…or use an ACME client…” has no clear or coherent instructions for HOW to do that. I have searched for DNS-01 and I get tons of stuff, but nothing which seems to tell me how to switch to another client.
Can someone point me at the correct instructions and perhaps fix the instructions above to point there as well, so fools like me dont get lost so easily?
More seriously, see https://letsencrypt.org/docs/allow-port-80/ which explains why opening port 80 is usually fine and also links to a list of ACME clients that support TLS-ALPN-01 in case you still don’t agree or can’t open port 80 because your ISP doesn’t allow it. The instructions are, of course, different for each one.
DNS-01 might be easier if you happen to be using a DNS service that Certbot supports - see https://certbot.eff.org/docs/using.html#dns-plugins for more on that option. Or you could try another client such as acme.sh which supports a wider variety of DNS services.
This confuses me even further. I have my domains (plural) through Godaddy. One domain apparently renews fine, the other gets this dns-o1 issue. So I dont see this as a DNS issue, but perhaps Im wrong.
So again, Im lost. Do I uninstall certbot/letsencrypt and install acme.sh? Install acme.sh in addition? Yall assume too much understanding. I just want my certs to work, I do not want to become an expert on all this stuff.
I further dont understand why the whole problem cannot be circumvented by simply telling certbot to use https instead of http. Instead, I have to figure out how to unscrew this problem.
Respectfully…then perhaps this free service isn’t the right fit for you and you should switch to a more traditional paid Certificate Authority that requires less expertise.
If you want a (relatively) simple and hassle-free experience, your best bet is to open port 80 as if you do that everything should “just work” in most cases. If you insist on keeping it closed and looking for another solution, read on … but you’re choosing to make things harder for yourself
Certbot doesn’t have a DNS plugin for GoDaddy, so that’s not an option.
If you want to try acme.sh, I’d suggest first installing it alongside certbot, following the instructions it provides to get your new certificates, switching your web server configuration to use those new certificates, and then finally (optionally) removing certbot after everything is working. acme.sh supports both TLS-ALPN-01 and GoDaddy’s DNS API, so both options are available (though I’ve personally only ever used acme.sh with HTTP-01 so I can’t swear by them myself).
It was originally planned to allow verification using HTTPS instead of HTTP, but this was scrapped due to a security issue around shared hosting. Currently the only way to “tell certbot to use https instead of http” is to open port 80 and configure it to serve a redirect to HTTPS.
I dunno, I think the mission of Let’s Encrypt is to remove the barriers to a fully encrypted web, and it wouldn’t do to remove one barrier (cost) only to replace it with another (difficulty). It was necessary to make this change, but it’s unfortunate that it was necessary to inconvenience users in the process (although probably unavoidable).
Absolutely, that would work fine. Note however that you would need to temporarily open it again for the next and subsequent renewals as well.
That is: port 80 needs to be open while you are renewing a certificate using HTTP-01, but can remain closed at all other times.
If you can script the opening and closing of the port, you can use certbot’s --pre-hook and --post-hook options to run those scripts automatically before and after each renewal attempt.
So I reread the whole post again. Perhaps I am being dense, it certainly wouldn’t be the first time. Can I open port 80, and then within the proxy just point it to 443? Will that work?
(I cannot just do it and test it because I cannot access the router/proxy remotely, will have to wait till I am onsite for that.)
If you mean you want to route your external port 80 to an internal port 443 so as to serve HTTPS on port 80 - well, you can do it, but it won’t work for the purposes of the HTTP-01 ACME challenge, so it won’t help you to renew your certificates.
What you can do is open port 80 and route it to a simple HTTP server that always responds with a redirect to HTTPS (preserving the URL path). Something like an Apache VirtualHost that does nothing but Redirect permanent / https://example.com/ (okay, maybe not the simplest example). Or if your proxy is smart enough, maybe it can serve such a redirect itself.
If you are implying a security concern, then I am interested in hear more about that.
In the interim, if you mean: Why would anyone allow http to a “secure system”?
An answer to that question can be as simple as.
Allowing http does not require it to reach a “secure system”.
So, if you are extremely security concious, you can have both “allowed” http and yet NOT reaching a “secure system” via http.
Simply place a device dedicated to only http anywhere on your network (preferably in a DMZ).
And route all the incoming http traffic to it.
It would only have the one job: To redirect all http traffic to https.
[which can be done on a raspberryPi - or a dedicated Linux VM with 1 CPU and 512MB mem (whichever is cheaper for you)]
Thanks for all the help and enlightenment. After some fiddling with my firewall, I discovered I had something mangled therein, and fixed it, and now the dry-run works correctly.
I guess I am a bit at a loss. Why are we making such an effort to encrypt and ensure non-repudiation, but because its a security concern, and silly me was somewhat surprised to discover that I had to have port 80 open for certbot to work… I guess I thought the whole point was to move everything off port 80 since by default, that traffic is not encrypted and subject to all sorts of MITM shenanigans.
So I began asking questions as to why I should have to open port 80, and basically was told that its necessary because to do what’s required on port 443 caused some vulnerability.
My lack of understanding aside, mark me fixed, cured, solved etc. Thanks for the help.
Just a point of clarification:
The LE renewal/cert process is not just http.
The client connects to LE via https (always).
[Towards the end of that secure conversation, the client is provided the challenge response (via https)]
So, only the response to the challenge question is sent over http.
[and this challenge response and that entire part of the “conversation” can be made completely public - there is nothing secretive in it]
Once LE has validated this (public) response it can proceed within the secure connection and provide the renewal cert.
