# Is there a reason that the challenge can't be over port 443? **URL:** \ **Category:** Feature Requests\ **Created:** [October 11, 2017, 12:35pm UTC](https://community.letsencrypt.org/t/is-there-a-reason-that-the-challenge-cant-be-over-port-443/44011 "2017-10-11T12:35:22Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![waynew](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/waynew/32/17231_2.png) [@waynew](https://community.letsencrypt.org/u/waynew)\ **Post date:** [October 11, 2017, 12:35pm UTC](https://community.letsencrypt.org/t/is-there-a-reason-that-the-challenge-cant-be-over-port-443/44011/1 "2017-10-11T12:35:22Z")
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? ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [October 11, 2017, 12:39pm UTC](https://community.letsencrypt.org/t/is-there-a-reason-that-the-challenge-cant-be-over-port-443/44011/2 "2017-10-11T12:39:10Z")
> [@waynew](#): > > 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! ---
**Author:** ![waynew](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/waynew/32/17231_2.png) [@waynew](https://community.letsencrypt.org/u/waynew)\ **Post date:** [October 11, 2017, 12:43pm UTC](https://community.letsencrypt.org/t/is-there-a-reason-that-the-challenge-cant-be-over-port-443/44011/3 "2017-10-11T12:43:46Z")
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! ---
**Author:** ![tialaramex](https://avatars.discourse-cdn.com/v4/letter/t/f08c70/32.png) [@tialaramex](https://community.letsencrypt.org/u/tialaramex)\ **Post date:** [October 11, 2017, 6:08pm UTC](https://community.letsencrypt.org/t/is-there-a-reason-that-the-challenge-cant-be-over-port-443/44011/4 "2017-10-11T18:08:16Z")
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. ---
**Author:** ![waynew](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/waynew/32/17231_2.png) [@waynew](https://community.letsencrypt.org/u/waynew)\ **Post date:** [October 12, 2017, 5:30pm UTC](https://community.letsencrypt.org/t/is-there-a-reason-that-the-challenge-cant-be-over-port-443/44011/5 "2017-10-12T17:30:59Z")
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](https://serverfault.com/q/878037/46824). 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 😉 ---
**Author:** ![Patches](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/patches/32/17145_2.png) [@Patches](https://community.letsencrypt.org/u/Patches)\ **Post date:** [October 12, 2017, 9:22pm UTC](https://community.letsencrypt.org/t/is-there-a-reason-that-the-challenge-cant-be-over-port-443/44011/6 "2017-10-12T21:22:10Z")
> [@waynew](#): > > ```plaintext > renew-by-default = True > > ``` 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. ---
**Author:** ![waynew](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/waynew/32/17231_2.png) [@waynew](https://community.letsencrypt.org/u/waynew)\ **Post date:** [October 13, 2017, 12:22am UTC](https://community.letsencrypt.org/t/is-there-a-reason-that-the-challenge-cant-be-over-port-443/44011/7 "2017-10-13T00:22:54Z")
Oddly named… I don’t have a cron job setup yet, but that’s useful to know for when I do 🙂 Thanks! ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [November 12, 2017, 12:23am UTC](https://community.letsencrypt.org/t/is-there-a-reason-that-the-challenge-cant-be-over-port-443/44011/8 "2017-11-12T00:23:00Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.