Whelp, cert rotation is one of those things that seems small at 20 services right up until one random internal app decides trust chains are a personal attack.

I’d separate the issue into two buckets:

Public/internal services that already work cleanly with ACME? Keep letting Let’s Encrypt do its thing if it’s behaving. Sure, the 90-day cert lifetime is annoying, but the automation model is good.

Internal only weird apps that break every renewal because they need a Java keystore, a Windows cert store import, a service restart, a bundled PEM path, the first full moon of the month, etc.? Those probably need a real internal process.

For \~20 services, an internal CA can be worth it if you do it stupidly boringly:

• one internal root/intermediate trusted by domain devices
• documented naming/SAN rules
• 1-year-ish internal leaf certs
• automation for issuance/deploy/restart
• monitoring that screams well before expiry
• an inventory of “where’d I put that cert,” because that is always the wooorst

The important bit is not internal CA vs Let’s Encrypt. It’s “do you have a repeatable deployment path per app?” Certbot renewing the file is only half the job. The app also has to reload it, import it, bind it, or whatever dance that particular service requires.

I’d probably keep Let’s Encrypt/ACME where it’s smooth, and move the delicate internal only stuff behind an internal CA or a reverse proxy/load balancer that owns TLS centrally. Centralizing TLS is the biggest quality of life upgrade if the apps themselves are allergic to cert rotation.

Just don’t switch because 90 days is annoying. Switch/centralize because your services don’t consume renewed certs reliably. Expiring certs are bad, but “the cert renewed successfully and the app is still using the old one” is where your eyes start accidentally drifting in different directions.