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?
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?
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
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.
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).
Yes, that's a big reason that the "Best Practice - Keep Port 80 Open" page recommends allowing HTTP with a redirect to HTTPS.
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!
Small things you can do that make it less likely ordinary users would try (and fail) to connect to HTTP:
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
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.
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.
Until it gets buggy and turned out to have a remotely exploitable vulnerability 
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).
All great things that I have advised many myself. 
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.
All true things. I was going more for the metaphorical, but yes, yet another piece of software presents yet another attack vector.
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.
Wise indeed. So... how much Microsoft software can I sign you up for...
None 
I believe OSS can be better checked/audited.
Another alternative is tls-alpn-01 challenges, which work on port 443 and don't need port 80 at all.
To be fair, Microsoft has been making a big switch to OSS in the past couple of years.