A suggestion: I confess my memory is poor and certificate renewal always seems to be a pain (I can never remember how I did it previously). I haven't seen well mentioned (could be wrong) and googling didn't really help, but I might suggest in a FAQ or a help the statement.
Before renewing (>sudo certbot --nginx -v) first check iptables using >sudo iptables -L
and then verify you have port 80 forwarded on your router. I always forget the latter, and this time I wasted a number of hours before figuring it out. I might suggest that the error message suggest checking both the firewall (which was fine) and router port forwarding.
Please see this page of the Let's Encrypt documentation:
Or is your tip specifically about NAT port maps?
Sorry, it has to do with port forwarding on routers between the WAN and LAN. Port 80 on both sides needs to be forwarded to the server machine. This is a foolish mistake I have made often, and it doesn't seem to be mentioned very often. Port 80 on the server machine was open, but the HTTP-1 frames never reached the server machine, but were refused by the router. Once I added the port forwarding, and waited the hour I was able to renew my certificates (I have two).
Why do you feel the need to shut down the port forwarding [while "not in use"]?
Does port 443 remain open?
Agreed, you may be finding that the documentation isn't clear for your use case because what you're doing sounds pretty unusual. Usually, you'd be in one of these cases:
- This is for a publicly-visible web server. In that case, port 80 would just be open all the time and if it wasn't "forwarded" to the right place then the issue isn't really about getting certificates, it's that your site is down and you don't know it.
- This is for an internal-to-your-network-only server. In that case, you'd either be using the DNS-01 challenge instead, or (if for whatever reason you needed to use HTTP-01 instead) you'd have configured certbot's hooks to open up your firewall and configure your forwarding and whatnot for you, so that it happens automatically whenever it needs to get a new certificate.
It sounds like you're doing some sort of manual intervention regularly, which as you've noticed is highly error-prone and not recommended as a way to do things at all.
In general, I don't like to forward any ports that aren't being used. I guess I could leave it open as nothing is listening for it.
I'm in situation #2. I haven't seen instructions on how to implement your suggestions. I would have thought that a moderately large number of users might be running a server behind a router (at least during development), and having step by step instructions on how to do this would certainly help me. If you have a link to such instructions, would you mind sharing it with me? I do not personally understand how to set up for challenges such as DNS-01 and/or HTTP-01, so again if you could direct me to a good how to, it would be beneficial.
Well, there are a lot of ways to set things up, depending on what you want to do, which I do understand can make it hard to know where to start.
I would start with trying to get DNS authentication working, rather than trying to fiddle with firewalls, assuming that your hostname's authoritative DNS server is publicly available even if the hostname itself is not. Ideally, it'd have an API with a certbot plugin, so you'd just need to install the corresponding plugin for your DNS provider, give it whatever credentials it needs to add and remove the TXT record, and that'd be all. If there isn't an API for certbot to use, then I'd look at acme-dns, which is a special-purpose DNS server that you can delegate the challenge to so that you can use an API for the record you need.
If you're happier with the HTTP-01 challenge, then either just keep port 80 open all the time, or set up the --pre-hook
and --post-hook
to scripts for whatever it is that you need to do in order to enable connections to reach your system.
If you give your actual domain name, DNS provider, and setup, it may be that people here could give more specific advice.