I’d be more concerned as well if this would be an over-night change, but I’d say that the rollout is slow and gradual enough that giving it more time would just lead to more procrastination instead, rather than finding solutions. Particularly for those following the news, which all sysadmins should, the reduction in certificate lifespan over time has been going on for a while now with a clear goal of automation becoming the only viable path forward.
I’ll also go out on a limb and make a guess that a not insignificant amount of people only think that their “special” case can’t be automated. I wouldn’t even be surprised if many of those could be solved by a bog-standard reverse-proxy setup.
Exactly. My “special case” took a little more care, but it works completely fine. Here’s my setup:
TCP proxy at edge -> wireguard tunnel using SNI to route to the right service
reverse proxy that handles all TLS for all services on its device (renewals and crypto)
HTTP services behind a firewall that only communicate w/ proxy
I have my router configured to resolve DNS to #2, so I don’t need to hit the WAN to access local services over TLS, and it uses the exact same cert as WAN traffic and the browser is happy.
This is about as exotic as I can think of, and it still works just fine for TLS renewals, and it’s 100% automated. I do need to leave HTTP open (it only serves acme endpoints, so whatever), but I could also close that down and have the renewal process open that temporarily if needed.
The only special case I can think of is a device that rarely turns on, which is incredibly rare these days (you’d generally have an always-on gateway that uses self-signed certs or something for those devices that stay off).
I’d be more concerned as well if this would be an over-night change, but I’d say that the rollout is slow and gradual enough that giving it more time would just lead to more procrastination instead, rather than finding solutions. Particularly for those following the news, which all sysadmins should, the reduction in certificate lifespan over time has been going on for a while now with a clear goal of automation becoming the only viable path forward.
I’ll also go out on a limb and make a guess that a not insignificant amount of people only think that their “special” case can’t be automated. I wouldn’t even be surprised if many of those could be solved by a bog-standard reverse-proxy setup.
Exactly. My “special case” took a little more care, but it works completely fine. Here’s my setup:
I have my router configured to resolve DNS to #2, so I don’t need to hit the WAN to access local services over TLS, and it uses the exact same cert as WAN traffic and the browser is happy.
This is about as exotic as I can think of, and it still works just fine for TLS renewals, and it’s 100% automated. I do need to leave HTTP open (it only serves acme endpoints, so whatever), but I could also close that down and have the renewal process open that temporarily if needed.
The only special case I can think of is a device that rarely turns on, which is incredibly rare these days (you’d generally have an always-on gateway that uses self-signed certs or something for those devices that stay off).