Renewing every 3 months , do not want to keep port 80 active have to reinstate it? Have to change .htaccess?

My issues are that I do not want to create port 80 active if ssl is available and also I block users that are not with certain ips... for example , a family website will allow only the ips of users who are family.

Every 3 months I must open my website to the world and allow resolution to port 80 in order to be able to renew?

1 Like

For example, when I typed recert none of the pages would recert so I would have to reload the port 80 host and also do things like make it so all ips can momentarioy access website? What if website is password protected for confidentiality must I temporarily remove passwords? Is there a specific ip address that will allow certbot only for security precaution?

1 Like

Hi @Sixpiece,

If you use the HTTP-01 challenge method, the answer to all of your questions is "yes": you must allow inbound connections on port 80 from any IP address during the challenge verification process. Let's Encrypt does not assist with whitelisting its validation IP addresses and they may change at any time.

There are two other allowed challenge methods to prove your control over a domain name.

Whether you can use one of the other methods depends on your setup (what Let's Encrypt client you are using, and whether you have API access to make DNS record updates). See also

5 Likes

I should also add that if you're using Certbot, you can use the --standalone method, in which case Certbot will create its own temporary web server listening on port 80 (separate from your regular web server application and without access to any files or web applications hosted by your regular server). In that case you could choose to make the regular web server not listen on port 80 at all, including during the time of the renewals, and just rely on Certbot's standalone server for this.

4 Likes

@schoen

That is an excellent strategy.

The only problem I foresee is that most web browsers default to http when manually entering domain names (where the protocol is unspecified).

2 Likes

Yes, that's a big reason that the "Best Practice - Keep Port 80 Open" page recommends allowing HTTP with a redirect to HTTPS.

3 Likes

I love the idea of a limited, ephemeral webserver taking up residence for only a brief moment then vanishing in a cloud of smoke. Fantastic!

:genie:

3 Likes

Small things you can do that make it less likely ordinary users would try (and fail) to connect to HTTP:

  1. HSTS - set HTTP Strict Transport Security for the site. This stops popular browsers from trying the unencrypted HTTP for your site so long as they remember they know about this, often months.

1a. HSTS-preloading. Several popular browsers agreed to use a list, created by Google, of sites that agreed to say they are HSTS and don't plan otherwise any time soon. For sites on this list, users needn't visit at all for their browser to learn never to use HTTP. However, you must have HSTS itself set up and working correctly first.

1b. Preloaded TLDs. All Google's new TLDs are HSTS preloaded. If you've got a .dev site, it has to have HTTPS because modern browsers will never try the HTTP protocol for the site. This likely will never happen to very famous old TLDs like .com but it may protect new sites you create with newer names

  1. If this is a sub-site, make sure all your links leading there from the main site are correctly HTTPS links. If there's no way for a user to accidentally click a link that goes to the HTTP site, very few users will go there.

  2. Make sure any SEO efforts you've made are directing people towards HTTPS rather than HTTP. In some media it may seem like you can just write yoursite.example and it works, but that may end up linking http://yoursite.example/ not https://yoursite.example/ so worth a moment to check.

3 Likes

Until it gets buggy and turned out to have a remotely exploitable vulnerability :grimacing:

If I would do something like that, personally I'd make sure a firewall was put up with some hooks to temporarily take it down. Outside of the main program running the webserver (i.e., wrap the ephemeral server within a script also taking care of the firewall).

2 Likes

All great things that I have advised many myself. :slightly_smiling_face:

The best thing would be if browsers would just default to https in the first place then (possibly) fallback to http. That, and people stop using the archaic www subdomain and its unnecessary redirect and duplication that all-too-often results in improper webserver configuration and missing certificate coverage.

I'm just amused by the "empty room" security. Nothing to see here. Literally.

1 Like

All true things. I was going more for the metaphorical, but yes, yet another piece of software presents yet another attack vector.

1 Like

However, I'll put my trust more in a program used and (hopefully) checked by thousands than a rather obscure piece of software not checked as much.

2 Likes

Wise indeed. So... how much Microsoft software can I sign you up for...

:smiling_imp:

2 Likes

None :grin: I believe OSS can be better checked/audited.

1 Like

Another alternative is tls-alpn-01 challenges, which work on port 443 and don't need port 80 at all.

1 Like

To be fair, Microsoft has been making a big switch to OSS in the past couple of years.

1 Like