New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
6-day and IP Address Certificates are Generally Available
(except apparently if you use certbot)
https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability
Short-lived and IP address certificates are now generally available from Let’s Encrypt. These certificates are valid for 160 hours, just over six days. In order to get a short-lived certificate subscribers simply need to select the ‘shortlived’ certificate profile in their ACME client.
...
Our default certificate lifetimes will be going from 90 days down to 45 days over the next few years, as previously announced.
Thanked by 1khalequzzaman
Comments
i don't like change
I think my certbot renew runs daily, so I can't imagine it actually making any difference at all. But personally, I think 10 days would have been better than 6 days as now it's almost certain to fail the day after you go on holiday for a week and 2 weekends.
Is there any reason to choose a short-lived cert rather than a 45 days cert?
I think mainly to test your pipeline before the ability to use 45 day certs ends. Or if you work on something like online banking where a leaked cert could be a massive security home as you can't always guarantee everyone has up-to-date revocation lists.
Finally. VULTR had a few IPv4 CIDR shorter and nicer started with 8.x for their VM clouds.
Why not for 6 hours? Or maybe even for 6 minutes?
IMO letsencrypt has become a joke with 90-days and soon 45-days "certificates". Or some party wants to drive people back to paid certificates, because that's what the result may be. I for one already returned to 3 yr and 5 yr paid certificates for way less than $5/yr. which is acceptable for avoiding the irritating letsencrypt games.
Good for you
And if others like what letsencrypt offers they can enjoy it.
Which providers are less than $5/year?
I like the use for it but again I know somebody is going to abuse this since they can just spin up a vps and host malware/phishing pages for a week then nuke it
People already do that
Those would preferably not use SSL certificates since they show up in transparency logs.
We are hoping @MannDude could launch IncogCA with 7-year certificates.
Renewing certificates every 2 months is getting tiring, and now we have to do it every week?
(Device has only 80KB RAM and cannot run certbot.)
This is a wider push by the people who actually work in that part of the industry - and definitely not just letsencrypt.
Certificate lifespan is going down quickly whether you like it or not.
Paid certificates will catch up eventually because browser developers are following this too - no point having a 3 year cert that nothing trusts.
5yr? What about security? I mean... 5 yr?
Edit: 5/yr ain't much but doesn't it get rather costy when you need a lot?
You might well be right, and maybe paid certificate providers will follow sooner or later.
BUT: (a) see below, my other response, and (b) those providers know WHY their customers purchase their certs and IMO will at least try to stand firm, because if they don't they lose many, many, if not most customers ~ they go "belly up".
In 9 out 10 cases I use a certificate I don't care a flying fuck about TLS security and the servers contents are publicly accessible anyway; the reason to have a certificate is only one: the "httpS everywhere!!!" idiots and the idiotic browser zealots.
I guess that larger customers will get lower prices, and anyway $5/yr likely is less than what keeping a herd of servers every x days up-to-date via acme costs. Also keep in mind that those cheap certificates need updating way less frequently.
yeah, its annoying me as well. Already had the same sentiment, that im sitting there every 3 hours updating the cert validations, to ensure that the cert which is supposed to be there is the cert that's actually being served.
Fair point. Looking at a broader usage case, I think multiyear certs shouldn't be trusted at all. For you security may not matter, for some it does.
Now,
, the updating could be an issue although you can easily get it done if you process them in batches. I addressed this on another thread.
Short-lived certs on ips won't be an issue as the number you'd need would be far less that actual domain certs so I think you could do that easily from a small cheap vm.
It wouldn't mind paying either but saving thousands a year by using let's encrypt. Just one server handling the certs + some additional ips. Not that bad at all for basically free certs.
Let's Encrypt is also working on a longer-term DNS validation method so you don't need to change validation values as often. This won't affect the 6-day IP certificates, because these must use HTTP validation anyway, but HTTP validation is very easy with < 200 lines of python. Nothing to complain about here.
This is a push from cloud providers/ members of the CA/Browser Forum because there are a lot of rogue certificates floating around for ephemeral VMs that are only up for 3 days anyway.
If you have been paying attention you'll also note that Let's Encrypt ditched OSCP Stapling and moved to traditional CRLs. OSCP was the hottest thing on the planet ~10 years ago but people realized that with billions of hostnames getting certificates it is getting too difficult.
I predict in the next ~3 years there will be a new certificate revocation methodology implemented.
Typical. Security poser makes no technical argument and doesn't understand why or even try to understand why this change is being made.
Yeah, I agree with you that on a public server, from an operator point-of-view, I don't much care about https over http because everything is public anyway, but from a user point-of-view it's nice that people other than the site itself can't eavesdrop and see what you were downloading, other than the domain name and the size of data transferred.
As soon as you have any private data or access keys, https becomes worth it.
From a personal standpoint, I held out on HTTP only on my personal websites and only reluctantly moved to HTTPS when the browsers started making non-HTTPS more hassle. Having to take time to learn how to use letsencrypt was annoying, but once it was done I was quite pleased how painless it was.
Now I've mostly to having multiple web server backends, letsencrypt is much more of a hassle, and it's a shame there's no simple solution and everyone has to craft their own. I'm happy with what I ended up with, but it is just another potential failure point I don't need.
Does current ssl certs was in any danger to be compromised? Why the change? There is some very pesky apps in dmz which needs valid certs. Shit :-/
Yes no and maybe. Last ~August Google forced all of the CAs (including Let's Encrypt) to no longer issue dual-use client/server TLS keys - TL;DR no more mTLS. Longer version: TLS certs from time immemorial had a bit set that you can use them both for server and client authentication. Google said they want to separate out certificates for servers and for clients into separate trust chains because security or some such nonsense (read: CA vendors want more money). And since that change was being brought in, a few other changes were floated, such as reducing the validity period of certificates - even commercial ones - to below current limits. The longevity of certificates, I think, was a casualty of the trust chain split.
Holy moly, I was only aware of this from your comment. Thanks!
As per https://letsencrypt.org/2025/05/14/ending-tls-client-authentication letsencrypt will not support TLS Client Authentication after May 13, 2026.
I still have some time to find an alternative CA
F... Google
Yeah, I spent some time trying to figure out how do generate my exim keys now because I'd always just been using letsencrypt to create them. Sometime into that fruitless task, I realised that you don't even need to properly sign that key anyway, as it's just a host key for TLS and you can self sign it without any problems.
I've not noticed any delivery problems since then, so hopefully I haven't just set myself up for failure!
If Google is behind it it's not good for us with very high likelihood.
Careful there! I'm not sure about email servers but I know from web servers and clients that TLS has a field which can be set to NoVerify ("don't check server's cert") but whose default is set to do verification of the target host's cert.
It's usually relatively easy to set it to NoVerify, BUT it has to be done on the client's side, so I guess your self-signed cert won't work reliably, and to make things worse all a sysadmin sees, if he looks very carefully and closely, is a hint in the logs because the clients do not send a "complaint" but simply don't continue.
I still have some time to find an alternative CA
Alternative CA is not going to help. This is a CA/B-wide change and will apply to commercial certs as well. Best option if you need mTLS is to not need mTLS by using VPN or by self-signing your keys. Fortunately in most mTLS configs that I can think of have you controlling both the client and the server so doing either the VPN or the self-signed option should work without much issue.
Same here with a few servers on legacy setups — hardware load balancers, Plesk environments with custom mail certs, Exchange servers — where ACME either can't be configured or requires manual intervention anyway. For those cases a paid DV or OV cert is just simpler and less stressful than debugging why certbot broke after an OS update.