Since the beginning of this year, Let’s Encrypt rolled out a new shortlived profile for certificates that make them valid for only 160 hours. The intention, as they say, is to encourage automation and reduce the window of certificate compromise (because revocation is somewhat a flakey thing).
Yet, I haven’t seen a lot of news about it since then. Hence the question: is this shorter cert thingy something you considered and deployed for your homelab?
As for me I’ve set up lego-acme with profile: "shortlived" on my rig. Lego runs on a bihourly cronjob, but only renews when a cert has >=3 days to expiry. It’s been pretty much a set-and-forget experience, although some more monitoring would be nice.
At work, I used ssh-signed certificates for Linux server access - those certs are only valid for about 15 minutes.
The whole idea of shorter lifetime certificates is to address if a certificate is compromised. (Especially for client certificates which, iirc, Let’s Encrypt no longer offers).
For a home lab? With no externally accessible services? Short-lived certs aren’t really a big deal. Nobody is going to be hacking your homelab, stealing your private keys, poisoning your internal DNS, and pointing you to a different, malicious service.
I had no idea “single use certificates” were a thing. It makes sense, although from my personal perspective I have always worked with managed identities and privilege escalation.
I have almost no internet facing services, although the two I have I might swap for the short lived variants. As you said, risk of misuse due to compromise goes down so that makes sense.
For my other services, they are all running on HTTPS, but only available internally over LAN or VPN, all with isolated VLANs sort of like a Hub Spoke model. The two certs that are internet facing are basically for getting access to my VPN. Might swap the internal services to short lived anyway if the automation works well, as I said before, it’s fully automated anyway.
If you’re a developer for an important open source project, they might.
Attacking the xz project wasn’t done because the attacker cared about anything that the xz maintainer had. It was because he was trusted and the software he maintained had been given a fair bit of trust by certain maintainers and could be compromised and used as a vector into other systems that indirectly relied on that open-source project.