(Replying to PARENT post)
If you're using a local iptables ruleset as your firewall, you can use the owner module [1] to filter by UID/GID, for example allow establishing connections from the user that runs your LE automation.
[1] - https://www.frozentux.net/iptables-tutorial/iptables-tutoria...
๐คq3k๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
The common solution to this problem is to deploy a HTTP(S) proxy (like Squid) for outgoing connections. These can operate based on things like the Host header rather than the destination IP. Your web server would be locked down to only allow outgoing connections to this proxy.
๐คpfg๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
Use the DNS challenge: no open ports or listeners on your machine, just set a DNS record.
๐คmholt๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
Have a separate host that handles all of the renewals (e.g. dns01 challenge), then pushes the updated cert to your webserver and reloads the nginx (or whatever process is required for your webserver/proxy).
๐คygjb-dupe๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
Is it possible to fix it more generally? You need to make the renewal request somehow, and that means there has to be an outbound request at some point.
๐คmikeash๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
This caused Let's Encrypt to fail.
I worked around this by temporarily allowing outbound connections, but I wonder whether this needs to be fixed more generally? It seems reasonable to me to block all outbound connections on a web server that isn't expected to need any. But Let's Encrypt's (perfectly reasonable) need to renew certificates breaks this assumption. Unfortunately, it doesn't seem easy to set up an exception on an IP-based firewall to allow Let's Encrypt outbound connections only. This makes automated renewals hard.