Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.
This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.
I’ve been dreading this switch for months (I still am, but I have been, too!) considering this year and next year will each double the amount of cert work my team has to do. But, I’m hopeful that the automation work I’m doing will pay off in the long run.
Are you not using LE certbot to handle renewals? I can’t even imagine doing this manually.
Personally, yes. Everything is behind NPM and SSL cert management is handled by certbot.
Professionally? LOL NO. Shit is manual and usually regulated to overnight staff. Been working on getting to the point it is automated though, but too many bespoke apps for anyone to have cared enough to automate the process before me.
I’m in the same boat here. I keep sounding the alarm and am making moves so that MY systems won’t be impacted, but it’s not holding water with the other people I work with and the systems they manage. I’m torn between manual intervention to get it started or just letting them deal with it themselves once we hit 45 day renewal periods.
Can you not just setup an nginx reverse proxy at the network edge to handle the ssl for the domain(s) and not have to worry about the app itself being setup for it? That’s how I’ve always managed all software personal or professional
Unfortunately some apps require the certificate be bound to the internal application, and need to be done so through cli or other methods not easily automated. We could front load over reverse proxy but we would still need to take the proxy cert and bind to the internal service for communication to work properly. Thankfully that’s for my other team to figure out as I already have a migration plan for systems I manage.
Why can’t you just have a long lived internally signed cert on your archaic apps and LE at the edge on a modern proxy? It’s easy enough to have the proxy trust the internal cert and connect to your backend service that shouldn’t know the difference if there’s a proxy or not.
Or is your problem client side?
That’s actually a really good idea. I’m not the person you replied to, but I’m taking notes.
One reason for the short certs is to push faster adoption of new technology. Yes that’s about new cryptography in the certs but if you still change all your certs by hand maybe you need to be forced …
Luckily I am using only traefik and everything goes through it that it needs for.
Can’t imagine how annoying it would be to interface with every equipment so there are no https errors…