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.
I’m happy with 90 day certs for homelab stuff: I’m not worried about anyone MITMing my network. I figure the short lived certs are more important for people who provide services with a significant external user-base, or who process sensitive transactions.
I have my certbot set to check every 12 hours and renew at 60 days. Renewing every 3 days would be 20x more load on Let’s Encrypt systems, and that feels like abuse of a free service for my use case.
I think they encourage that increased frequency by offering shortlived certs to begin with…
Although do note that normal certificates will reduce its lifetime to 45 days over the next few years
Certs get cut in half in the next couple of years.
No, and if there was an option for a 20-year certificate I would have taken it.
Honest, non-techie question: How is it an advantage? Given modern crypto isnt it more likely that a mitm didn’t crack the crypto but instead got somehow else in the middle and just can “ignore” certs renewals?
A private key leaking is bad, since anyone with the private key can decrypt data that was encrypted with it.
Traditionally, the way that leaked certs were handled was via Certificate Revocation Lists (CRL). CRLs contain lists of revoked certificates - their serial number, revocation date, and the reason why they were revoked.
However, CRLs are imperfect. Checking for revoked certificates every time you go to a site would slow things down a lot, as the lists are now too large to check and download real-time. Modern browsers and other TLS clients periodically download the lists in the background. Also, it might take a while between when the certificate is compromised and when the company notices the compromise.
Because of this, the CA/Browser forum (a group with all the major browser and TLS certificate vendors) have started dropping the max lifetime of certificates. The idea is that even if a private key does leak, the time frame that it’s usable for will be significantly shorter and any leaks should (in theory) cause less damage.
- The original maximum duration was 39 months: Three years plus an extra three months leeway for obtaining and deploying new certificates.
- March 2018: Reduced to 825 days
- September 2020: Reduced to 398 days
- March 2026: Reduced to 200 days
- March 2027: Planned to reduce to 100 days
- March 2028: Planned to reduce to 47 days
All modern deployments, regardless of if they’re using free or paid certs, should have their renewals fully-automated, so in theory the validity period shouldn’t matter as much as it did in the past. All major vendors (Let’s Encrypt, DigiCert, Sectigo, GlobalSign, AWS, SSL .com, etc) support ACME now. Reducing the validity is also a forcing function t o ensure automation is actually implemented.
somehow else in the middle and just can “ignore” certs renewals?
I’m not sure that’s possible, since an attacker in the middle shouldn’t be able to obtain a valid certificate for the domain. Certificates have a “not valid after” date encoded into them, after which the certificate is considered invalid and you get an error.
The real value is in the agility needed to update certs every six days.
Six days is still too long to leave a compromised key in play, but anyone who can rotate their keys every six days can probably also rotate their keys quite quickly if there’s a comprise.
You’re gonna get different viewpoints, ranging from “yeah, but it’s popular” to “shut up”.
Since the certificate revocation list doesn’t really work. They decided to shorten certificates lifespan. 90 days down to 45 and who knows what is next.
Yes, with Caddy and haven’t noticed a thing, and had no complaints. So it has been perfectly fine and it is all automated.
I migrated from vanilla Nginx Proxy Manager to NPMplus (because of CrowdSec), and it defaults to short-lived certificates. Other than temporarily making my Uptime Kuma SSL monitors completely freak out because my certificates “were too close to expiration”, everything still works exactly the same.
Interesting, I didn’t know NPMplus was a thing. Looks like I’ve got some researching and possibly reconfiguring to do…
I’m just using regular Nginx, which I’ve been using for 20 years. What does Nginx Proxy Manager or npmplus do better?
I’ve been meaning to try Angie too, which is a fork of Nginx.
Not really sure they do anything “better”, it’s mainly for convenience. It’s an all-in-one solution with a nice UI and sane defaults. That helps me have a somewhat consistent setup across all my hosted services. If you’re happy with managing Nginx directly, then you probably have no reason to use these.
Makes sense! I didn’t realise it has a UI.
I’ve got a bunch of snippets in
/etc/nginx/snippets/, so for example I just need to addinclude snippets/proxy.confto a server block to add most of the configuration needed for a reverse proxy. I’ve been using Nginx for long enough that I just write the rest of the server block by hand.
One step closer to single use certificates. Great…
So much certificate wrapper waste in the landfills. Smh
Everyone in here taking about an the automations they’ve done for certs and I just use Caddy. It handles all that for me.
Caddy is a good piece of software.
I’ve been using Nginx for 20 years and don’t really have a reason to switch, so I’m still using it. I use certbot, so it’s just one command to create the certificate initially, and then it auto-renews automatically via a systemd timer.
I plan to operate on expired certificates for two to four years, forcing all three of my users to click past a terrible warning.
Then I will automate my six day certificate rotation with Ansible (officially), but maybe actually with a stupid bash script in CRON (unofficially).
Certbot came with a systemd timer running twice a day (0, 12 +12h random) that only renews –iirc– when the certificate has 30 days or less to live. Also I looked it up and my (version 6.7) Certbot neither mentions the option with the --help option, nor in the manual (where there is just one instance of “profiles exist, no other details given”).
So they probably need another way than a random blog post when they want users to use (or even just know about) that option…
It’s been pretty much a set-and-forget experience
Yeah, that’s what it always has been. So no need to change anything unless they make it the new standard on their side with an update…
@Ooops @stratself Certbot renews a certificate when the remaining lifetime is lower than 30 %. If you change the profile from tlsserver (90 days) to shortlived (6 days), you do not need to adjust the renewal interval manually, because it is relative to the cert livetime.
I think it is not Letsencrypt’s part to document how to use the different profiles with certbot. It should be explained in the documentation of the ACME client (certbot and others).I know that I could easily change my config. My point is that a) they are failing to advertise this and b) I don’t see any reason to do it. I understand the arguments about security benefits of shorter certificates on their side and iirc they are already planning to change it from 3 months to 1.5 months in the future. But in what scenario do I benefit from a short-term certificate as long as the regular ones are still available anyway?
@Ooops I do not understand what you mean with “they are failing to advertise this”. Letsencrypt has announced in in their blog:
https://letsencrypt.org/2025/01/16/6-day-and-ip-certs
https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued
The profiles are documented:
https://letsencrypt.org/docs/profiles/
It is your deciscion what profile to use. If you use the shortlived profile and your key is compromised, you benefit from the short lifetime. This benefit you have regardless of the availability of the 90 day certs.If you use the shortlived profile and your key is compromised, you benefit from the short lifetime.
Maybe I’m just too stupid to understand how those certificates work.
But in what scenario is my key compromised but not my server? Because someone getting control of my server can just get an new long-term certificate. That was my actual point in the comment above. I understand the argument of added security if they only issue short-term certificates. But where is the benefit of my short-term certificate when someone compromising my server can just get a new long-term one in seconds?
Also we are talking about self hosting. I understand the issue of revoking certificates when you have a massive userbase where some might miss the revocation for quite some time. Not so much with the dozen max family and friends.
I’m using Nginx Proxy Manager. Apparently my letsrenew certs are good for 2 yrs and I don’t see any way to configure that in the ui.
No, that’s stupid.
NPM renews my certs for me, anyway.
I don’t know what the BFD is. Noone is supposed to handle certs manually anyway. OK, maybe companies that did not get the message but nowadays this is supposed to be automated and then it does not really matter whether the cert is valid for 90, 45, 30, or 6 days.
For security, it does matter, shorter is better.
Not 6 day but already set under what it’s going to be worldwide in 2029. https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days
No, because I often use Cloudflare, and I end up getting emails when Cloudflare notices a new SSL cert, and I don’t want to get those emails every 6 days. I already get more than enough emails in general.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters CA (SSL) Certificate Authority DNS Domain Name Service/System TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network
[Thread #119 for this comm, first seen 7th Oct 2026, 05:50] [FAQ] [Full list] [Contact] [Source code]
