3 ms·
> Is it possible to fix it more generally? It's a good question. I'm not sure. It is, however, a caveat of the Let's Encrypt experience for me - whether or not
by rlpb 10y ago
> Is it possible to fix it more generally?
It's a good question. I'm not sure. It is, however, a caveat of the Let's Encrypt experience for me - whether or not it is possible to fix.
> You need to make the renewal request somehow, and that means there has to be an outbound request at some point.
Agreed. It would be nice if there were some way to set up an (external) IP-based firewall such that the Let's Encrypt API calls can go through, but nothing else.
One way might be to declare publish destination IPs as static (rather than dynamically through DNS), but of course this would be rather brittle for them from a service perspective.
Another way might be to get a port number assigned for the ACME protocol, rather than overloading HTTPS. ACME services could operate on both an official ACME port number as well as the HTTPS port for backwards compatibility. The protocol could remain HTTPS-based. Then firewalls could explicitly allow ACME through, while blocking outbound HTTPS for anything else that may be an attempt to exploit a general HTTPS server rather than being known to be ACME-specific.
- mikeash 10y agoHow practical would it be to route the outbound requests through another machine (or VM?) which has more privileges, but is locked down to do nothing but send ACME requests? Or have that VM be entirely in charge of certificate renewal, and give it access to your certificate store somehow?
- rlpb 10y ago> Or have that VM be entirely in charge of certificate renewal, and give it access to your certificate store somehow? This is what I'd prefer, I think. The thing is, part of the appeal of Let's Encrypt is the readily available ACME client that JFDI. Such an easy-to-use client doesn't currently exist for this use case.