Start from the idea that you're going to issue certificates valid for 24 hours, and think how different your environment would need to look.
Start from the idea that you're going to issue certificates valid for 24 hours, and think how different your environment would need to look.
I renew once a month, and if things should break, I have a two month window to fix the issues.
Before that I would receive a Comodo SSL Certificate once a year via email and until then I always had forgotten what I had to do with it. What an unnecessary pain.
(Ideally, you'd remember and never set the alert off, but still great to have that extra layer.
Anyway, the best is to shorten the certificates validity. The way Letsencrypt recommends is perfect, run it often and require several failures before anything breaks.
I'm not advocating against it, just exposing the whole story.
This grants you 30 days to fix any problems and get the system back up.
Pretending it's "totally static" is exactly the problem. There are only two kinds of things in the software world - things that can stay the same until your next release, and things that need automation. "Almost completely static" is how your post mortem ends up on the front page of HN.
A consideration of the full story also needs to include the risks associated with long-lived certificates. If you lose control of the private key associated with one, what do you do? Are you actually operating a CRL? Are any of your HTTPS clients actually checking the CRL? What would you do if a severe compromise were discovered that affected the signature algorithm you're using?