I can imagine both cases being true, that the renewal process is automated and that certs won't get renewed because institutional knowledge has left the door. Where I'm at, service-to-service TLS certificates (the bulk of our certs) are automatically rotated by our deploy systems. But there are always the edge cases: the certificates manually created a long time ago (predating any standardized monitoring systems) with long expiry dates, and certificates for systems that simply can't run off the standard infrastructure. Sometimes, they'll bring down systems with low SLOs; other times, they'll block all internal development.
> the certificates manually created a long time ago (predating any standardized monitoring systems) with long expiry dates
Like the ever-popular "expires in 10 years" long-lived certificates. I've seen that happen: the VPN certificate, probably created by one of the founders 10 years ago when the company was tiny, expired one day without warning, breaking the VPN for all employees until it could be replaced (manually on every device).
They aren't talking about the front-end certificates which expire in Feb 2023.
It's likely the ones to encrypt all of the traffic involving the Finagle micro-services, data sources, observability systems etc. And I suspect the issue there is that you are going to need to do a rolling restart.
Which I personally would not want to be doing if 90% of the company is no longer there.
The way TLS was integrated into Finagle, most services should not need to be restarted to pick up and use their new certs. That said, there are certain core services that will require manual intervention, and there will inevitably be some services that should auto-update but do not.
