# Confusing instructions, again **URL:** \ **Category:** Help\ **Created:** [January 26, 2019, 2:01pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107 "2019-01-26T14:01:17Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![alabamatoy](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/alabamatoy/32/15894_2.png) [@alabamatoy](https://community.letsencrypt.org/u/alabamatoy)\ **Post date:** [January 26, 2019, 2:01pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/1 "2019-01-26T14:01:17Z")
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? ---
**Author:** ![jmorahan](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jmorahan/32/1873_2.png) [@jmorahan](https://community.letsencrypt.org/u/jmorahan)\ **Post date:** [January 26, 2019, 2:08pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/2 "2019-01-26T14:08:46Z")
> [@alabamatoy](#): > > why would anyone allow http? Why, to redirect it to HTTPS, of course 😛 More seriously, see [Best Practice - Keep Port 80 Open - Let's Encrypt](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 [User Guide — Certbot 2.7.0.dev0 documentation](https://certbot.eff.org/docs/using.html#dns-plugins) for more on that option. Or you could try another client such as [acme.sh](https://github.com/Neilpang/acme.sh) which supports a wider variety of DNS services. ---
**Author:** ![alabamatoy](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/alabamatoy/32/15894_2.png) [@alabamatoy](https://community.letsencrypt.org/u/alabamatoy)\ **Post date:** [January 26, 2019, 2:20pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/3 "2019-01-26T14:20:30Z")
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. Thanks for the help. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [January 26, 2019, 6:54pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/4 "2019-01-26T18:54:15Z")
> [@alabamatoy](#): > > I just want my certs to work, I do not want to become an expert on all this stuff. 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. ---
**Author:** ![jmorahan](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jmorahan/32/1873_2.png) [@jmorahan](https://community.letsencrypt.org/u/jmorahan)\ **Post date:** [January 26, 2019, 7:32pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/5 "2019-01-26T19:32:08Z")
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). > [@alabamatoy](#): > > I further dont understand why the whole problem cannot be circumvented by simply telling certbot to use https instead of http. 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. > [@rmbolger](#): > > 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. 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). ---
**Author:** ![alabamatoy](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/alabamatoy/32/15894_2.png) [@alabamatoy](https://community.letsencrypt.org/u/alabamatoy)\ **Post date:** [January 26, 2019, 8:32pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/6 "2019-01-26T20:32:53Z")
> [@jmorahan](#): > > > [@rmbolger](#): > > > > 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. > > 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). I certainly agree. Does 80 have to remain open, or can I open it, do the update, then close it again? I may be able to temporarily move the connection outside the FW if it will work post-update. ---
**Author:** ![jmorahan](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jmorahan/32/1873_2.png) [@jmorahan](https://community.letsencrypt.org/u/jmorahan)\ **Post date:** [January 26, 2019, 8:34pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/7 "2019-01-26T20:34:36Z")
> [@alabamatoy](#): > > can I open it, do the update, then close it again? 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. ---
**Author:** ![alabamatoy](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/alabamatoy/32/15894_2.png) [@alabamatoy](https://community.letsencrypt.org/u/alabamatoy)\ **Post date:** [January 26, 2019, 8:48pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/8 "2019-01-26T20:48:30Z")
> [@jmorahan](#): > > > [@alabamatoy](#): > > > > why would anyone allow http? > > Why, to redirect it to HTTPS, of course 😛 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.) ---
**Author:** ![jmorahan](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jmorahan/32/1873_2.png) [@jmorahan](https://community.letsencrypt.org/u/jmorahan)\ **Post date:** [January 26, 2019, 8:55pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/9 "2019-01-26T20:55:40Z")
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. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [January 27, 2019, 10:03pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/10 "2019-01-27T22:03:25Z")
> [@alabamatoy](#): > > why would anyone allow http? 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)] ---
**Author:** ![alabamatoy](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/alabamatoy/32/15894_2.png) [@alabamatoy](https://community.letsencrypt.org/u/alabamatoy)\ **Post date:** [January 27, 2019, 11:29pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/11 "2019-01-27T23:29:48Z")
> [@jmorahan](#): > > {showing lots of patience with a befuddled user....) 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. > [@rg305](#): > > > [@alabamatoy](#): > > > > why would anyone allow http? > > If you are implying a security concern, then I am interested in hear more about that. 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. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [January 27, 2019, 11:35pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/12 "2019-01-27T23:35:39Z")
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. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [February 26, 2019, 11:35pm UTC](https://community.letsencrypt.org/t/confusing-instructions-again/84107/13 "2019-02-26T23:35:41Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.