This is a pretty common topic around the web, but most of the things I’ve seen are asking for arbitrary ports open. I just recently read a thing about CAB that listed a couple of ports, and among them is 443.
My ISP only blocks 25 (in and out) and 80.
It doesn’t block 443.
Is there a reason that the challenge can’t or shouldn’t happen just over port 443?
Hi @waynew,
ACME, the protocol that the Let's Encrypt server and clients like Certbot speak supports three challenge types presently: HTTP-01, TLS-SNI-01 and DNS-01.
Only HTTP-01 challenges arrive on port 80. TLS-SNI-01 challenges arrive on port 443 and should work without any problem in your environment. DNS-01 challenges don't make an inbound request to the webserver at all and the CA only has to talk to your authoritative nameserver.
That gives you two options (TLS-SNI-01 and DNS-01) that you could use today 
What ACME client are you using? If you specify its likely someone in the forum can give you concrete advice on how to switch to using TLS-SNI-01 challenges.
Thanks!
It’s been a while since I’ve used one, precisely because that reason - and it was too much of a pain to log in to my nameserver and change the DNS record 
. But knowing that there’s a method that supports just over 443, I should be able to figure it out - I’m sure I’ll come update this with either my success story or what problems that I faced!
Thanks!
For information, the original design of http-01 offered optionally to use HTTPS on port 443 to do the same as you can do today with port 80. This was removed because of a common misconfiguration on shared hosting systems in which one customers site (often the alphabetically first but sometimes at random) would be delivered to systems like Let’s Encrypt if they asked over HTTPS for a different site perhaps owned by another customer who didn’t actually have HTTPS enabled. Although this mistake wasn’t Let’s Encrypt’s fault it would have left customers of those shared hosting providers vulnerable for little good reason, so http-01 is not used with HTTPS.
Well, yesterday was a long day filled with me learning all kinds of interesting fun and exciting things!
The first thing that I tried was to just renew my old certs. This didn’t work, probably because they had expired a few months ago.
I’m running Nginx so I tried using the --nginx plugin but I got some weird errors - turns out I had a .ini file in /etc/letsencrypt/cli.ini. And, surprise! It was causing some problems. So I got that squared away and was able to renew my first domain, but the second one was having problems. I ended out splitting my config file into two different ones - one for nginx and one for standalone. For some reason I had to rename it from cli.ini though. Well, I finally figured out the problem with Nginx. Turned out I needed to fix my config.
So this morning I tried renewing my certs, but it was having some weird problems with stuff in the renewal folder, so I backed my stuff up:
# mkdir $(date +%F)-bak
# mv renewal $(date +%F)-.bak
# mv live $(date +%F)-.bak
# mv archive $(date +%F)-.bak
# mkdir renewal live archive
Then, since I fixed my SSL config issues with nginx I went ahead and made a cli.ini again:
server = https://acme-v01.api.letsencrypt.org/directory
email = waynew@example.com
authenticator = nginx
agree-tos = True
renew-by-default = True
preferred-challenges = tls-sni-01
Then I ran certbot -d one.example.com -d two.example.com - but that failed because I had just removed the certs from nginx so it couldn’t reload the config. What I ended out doing was commenting out the SSL directives and then running again. This worked, but it put both of my domains in the same cert file, which I didn’t exactly want. So I backed up that information and made new files and then commented out the SSL info in my nginx file again. Then I ran:
# certbot -d one.example.com
# certbot -d two.example.com
And now I have two certs and two renewal config files and everything looks like it should be A-OK.
If I don’t come back and say something about it, you can assume that renewal worked just fine in a couple of weeks 
This option will make certbot obtain a certificate every time renewal is attempted instead of waiting until 30 days before it expires. If you have a cronjob for certbot renew (or your distribution provided one for you) you will likely obtain 1-2 new certificates per day until you hit the rate limit.
You should remove this option; it's unnecessary and dangerous.
Oddly named… I don’t have a cron job setup yet, but that’s useful to know for when I do 
Thanks!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.