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.
You must log in or register to comment.
Just saying:
There are alternatives for LE,not for all things, but for a lot. Afaik not all of them do follow suit.
I’m trying to think of the last time I heard news about something to do with the internet getting better instead of worse, and I’m genuinely coming up blank.
Let’s all just start self signing in protest
Reducing the validity timespan will not solve the problem, it only reduces the risk. And how big is that risk really? I’m an amateur and would love to see some real malicious case descriptions that would have been avoided had the certificate been revoked earlier…
Anybody have some pointers?
Terminology: revoked means the issuer of the certificate has decided that the certificate should not be trusted anymore even though it is still valid.
If a attacker gets access to a certificates key, they can impersonate the server until the validity period of the cert runs out or it is revoked by the CA. However … revocation doesn’t work. The revocation lists arent checked by most clients so a stolen cert will be accepted potentially for a very long time.
The second argument for shorter certs is adoption of new technology so certs with bad cryptographic algorithms are circled out quicker.
And third argument is: if the validity is so short you don’t want to change the certs manually and automate the process, you can never forget and let your certs expire.
We will probably get to a point of single day certs or even one cert per connection eventually and every step will be saver than before (until we get to single use certs which will probably fuck over privacy)
It really just helps in cases where you get hacked, but the hacker doesn’t have continued access. Say someone physically penetrates into your building, grabs the key through an unlocked station, and leaves.
That being said, like you mentioned, if someone is going through this effort, 45 days vs 90 days likely won’t matter. They’ll probably have the data they need after a week anyways.
Encryption key theft really requires a secondary attack afterwards to get the encrypted data by getting into the middle and either decrypting or redirecting traffic. It’s very much a state level/high-corporate attack, not some random group trying to make a few bucks.
No, but I have a link showing how ISPs and CAs colluded to do a MITM https://notes.valdikss.org.ru/jabber.ru-mitm/
Shorter cert lifespan would not prevent this.
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.
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…
Just let me know so I can change my crontabs.
It’s the “change your password often odyssey” 2.0. If it is safe, it is safe, it doesn’t become unsafe after an arbitrary period of time (if the admin takes care and revokes compromised certs). If it is unsafe by design, the design flaw should be fixed, no?
Or am I missing the point?
The point is, if the certificate gets stolen, there’s no GOOD mechanism for marking it bad.
If your password gets stolen, only two entities need to be told it’s invalid. You and the website the password is for.
If an SSL certificate is stolen, everyone who would potentially use the website need to know, and they need to know before they try to contact the website. SSL certificate revocation is a very difficult communication problem, and it’s mostly ignored by browsers because of the major performance issues it brings having to double check SSL certs with a third party.
The point is, if the certificate gets stolen, there’s no GOOD mechanism for marking it bad.
That’s what OCSP is for. Only Google isn’t playing along as per that wiki entry.
That’s what Carla are for.
But browsers have a marker for dangerous sites - surely Cloudflare, Amazon or Google should have a report system and deliver warnings at the base
Browsers are only a (large) fraction of SSL traffic.
So is there an example of SSL certs being stolen and used nefariously. Only thing that sticks out to me is certificate authorities being bad.
Yep. https://fedia.io/m/selfhosted@lemmy.world/t/3090624/Decreasing-Certificate-Lifetimes-to-45-Days/comment/13237364#entry-comment-13237364
Short lifespans are also great when domains change their owner. With a 3 year lifespan, the old owner could possibly still read traffic for a few more years.
When the lifespan ist just 30-90 days, that risk is significatly reduced.
Only matters for LE certs.
You can still buy 1 year certsFor 3 more months or so, you can’t buy them in april 2026 anymore
oh? Damn
So what’s the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1? Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
It is ignoring the elephant in the room – the central root CA system. What if that is ever compromised?
Certificate pinning was a good idea IMO, giving end-users control over trust without these top-down mandated cert update schedules. Don’t get me wrong, LetsEncrypt has done and is doing a great service within the current infrastructure we have, but …
I kind of wish we could just partition the entire internet into the current “commercial public internet” and a new (old, redux) “hobbyist private internet” where we didn’t have to assume every single god-damned connection was a hostile entity. I miss the comraderie, the shared vibe, the trust. Yeah I’m old.
Is this the same trust that would infect a box in under a minute if not behind a router?
The same trust of needing to scan anything you downloaded for script kiddie grade backdoors?
Zero click ActiveX / js exploits?
Man I’m probably the same age and those are some intense rose colored glasses 😅
Oh, definitely rose-coloured, but I am thinking even before those days… like when access to Usenet was restricted to colleges and universities, dial-up BBSes … and I didn’t use Windows or MacOS at all back then. ActiveX and js didn’t even exist back then. Boot-sector floppy viruses did, but those were easy to guard against.
where we didn’t have to assume every single god-damned connection was a hostile entity
But you always did, it was always being abused, regularly. That’s WHY we now use secure connections.
I think I’m just not picking up whether you’re actually trying to pitch a technical solution, or just wishing for a perfect world without crime.
More the latter :) … if only we could all just get along and be nicer to each other. Sigh.
Partition the internet… Like during the Morris worm of '88, where they had to pull off regional networks to prevent the machines from being reinfected?
The good old days were, maybe, not that good. :)
Well that could be considered the point where we lost our innocence, yeah. :(
Imagine trying to do this (excluding China, Russia and some middle eastern or african countries) in the western world.
I would assume total anarchy (especially in the stock trade lol)
Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
Automate your certificate renewals. You should be automating updates for security anyway.
But can you imagine the load on their servers should it come to this? And god forbid it goes down for a few hours and every person in the world is facing SSL errors because Let’s Encrypt can’t create new ones.
This continued shortening of lifespans on these certs is untenable at best. Personally I have never run into a situation where a cert was stolen or compromised but obviously that doesn’t mean it doesn’t happen. I also feel like this is meant to automate all cert production which is nice if you can. Right now, at my job, all cert creation requires manually generating a CSR, submit it to a website, wait for manager approval, and then wait for creation. Then go download the cert and install it manually.
If I have to do this everyday for all my certs I’m not going to be happy. Yes this should be automated and central IT is supposed to be working on it but I’m not holding my breath.
I doubt they will drop below 1-2 weeks. Any service outage would turn into a ddos when service was restored.
The entire renewal process is fairly cheap, resource wise. 7 day certificates are already a thing.
In terms of bandwidth you could easily renew a billion certificates a day over a gigabit connection, and in terms of performance I recon even without specialized hardware a single system could keep up with that, though that also depends on the signature algorithms employed in the future of course.The dependence on these servers is the far bigger problem I’d say.
This shortening of lifetimes is a slow change, so I hope there will be solutions before it becomes an issue. Like keeping multiple copies of certificates alive with different providers, so the one in use can silently fall through when one provider stops working. Currently there are too few providers for my taste, that would have to improve for such a system to be viable.Maybe one day you’ll select a bundle of 5 certificate services with similar policies for creating your certificate the way you currently select a single one in certbot or acme.sh
This is one of the reasons they’re reducing the validity - to try and convince people to automate the renewal process.
That and there’s issues with the current revocation process (for incorrectly issued certificates, or certificates where the private key was leaked or stored insecurely), and the most effective way to reduce the risk is to reduce how long any one certificate can be valid for.
A leaked key is far less useful if it’s only valid or 47 days from issuance, compared to three years. (note that the max duration was reduced from 3 years to 398 days earlier this year).
From https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days:
In the ballot, Apple makes many arguments in favor of the moves, one of which is most worth calling out. They state that the CA/B Forum has been telling the world for years, by steadily shortening maximum lifetimes, that automation is essentially mandatory for effective certificate lifecycle management.
The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information.
The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support.
note that the max duration was reduced from 3 years to 398 days earlier this year)
Oh… Oops. Hahaha
Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
Certbot’s default timer checks twice a day if it’s old enough to be be due for a renewal… So a change from 90 to 1 day will in practice make no difference already…
Good point. On that note I am very happy having moved my home server from Apache to Caddy. The auto cert config is very nice.
So what’s the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1?
LE is beta-testing a 7-day validity, IIRC.
Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
No, those are expected or even required to be automated.
7-day validity is great because they’re exempt from OCSP and CRL. Let’s Encrypt is actually trying 6-day validity, not 7: https://letsencrypt.org/2025/01/16/6-day-and-ip-certs
Another feature Let’s Encrypt is adding along with this is IP certificates, where you can add an IP address as an alternate name for a certificate.
Ah, well. I only remembered something about a week.
The current plan is for the floor to be 47 days. https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days, and this is not until 2029 in order to give people sufficient time to adjust. Of course, individual certificate authorities can choose to have lower validity periods than 47 days if they want to.
Essentially, the goal is for everyone to automatically renew the certificates once per month, but include some buffer time in case of issues.
The best approach for securing our CA system is the “certificate transparency log”. All issued certificates must be stored in separate, public location. Browsers do not accept certificates that are not there.
This makes it impossible for malicious actors to silently create certificates. They would leave traces.
Isn’t this just CRL in reverse? And CRL sucks or we wouldn’t be having this discussion. Part of the point of cryptographically signing a cert is so you don’t have to do this if you trust the issuer.
Cryptography already makes it infeasible for a malicious actor to create a fake cert. The much more common attack vector is having a legitimate cert’s private key compromised.
No, these are completely separate issues.
- CRL: protect against certificates that have their private key compromised
- CT: protect against incompetent or malicious Certificate Authorities.
This is just one example why we have certificate transparency. Revocation wouldn’t be useful if it isn’t even known which certificates need revocation.
The National Informatics Centre (NIC) of India, a subordinate CA of the Indian Controller of Certifying Authorities (India CCA), issues rogue certificates for Google and Yahoo domains. NIC claims that their issuance process was compromised and that only four certificates were misissued. However, Google is aware of misissued certificates not reported by NIC, so it can only be assumed that the scope of the breach is unknown.
Or the more likely a rouge certificate authority giving out certs it shouldn’t.
This seems like a good idea.
The only disadvantage I see is that all my personal subdomains (e.g. immich.name.com and jellyfin) are forever stored in a public location. I wouldn’t call it a privacy nightmare, yet it isn’t optimal.
There are two workarounds:
- do not use public certificates
- use wildcard certificates only
But how to automate wildcard certificate generation? That requires a change of the txt record and namecheap for instance got no mechanism for that to automatically happen on cert bot action
Doesn’t caddy support that (name cheap txt mod) via a plug-in?
I haven’t tried it yet, but the plugin made it sound possible. I’m planning to automate on next expiration… When I get to it ;)
I did already compile caddy with the plugin, just haven’t generated my name cheap token and tested.
There are some nameserver providers that have an API.
When you register a domain, you can choose which nameserver you like. There are nameservers that work with certbot, choose one that does.
Namecheap supports this according to docs. I just haven’t tested yet.
Not exactly what you mean because there are also bad actors but take a look at i2p, in some ways it feels like an retro internet.
Seeing as most root CA are stored offline compromising a server turned off is not really possible.
I’m more annoyed that I have 10 year old gear that doesn’t have automation for this.
Signing (intermediate) certs have been compromised before. That means a bad actor can issue fake certs that are validated up to your root ca certs
While you can invalidate that signing cert, without useful and ubiquitous revocation lists, there’s nothing you can do to propagate that.
A compromised signing certs, effectively means invalidating the ca cert, to limit the damage
Oh, I’m really just pining for the days before the ‘Eternal September’, I suppose. We can’t go back, I know. :/
As some selfhosting novice who uses NPM with auto renewal - I feel that I shouln’t be ocncerned.
Check your autorenewal failure alerts go somewhere you’ll react to.
Reducing the valid time will not solve the underlying problems they are trying to fix.
We’re just gonna see more and more mass outages over time especially if this reduces to an uncomfortably short duration. Imagine what might happen if a mass crowdflare/microsoft/amazon/google outage that goes on perhaps a week or two? what if the CAs we use go down longer than the expiration period?
Sure, the current goal is to move everybody over to ACME but now that’s yet another piece of software that has to be monitored, may have flaws or exploits, may not always run as expected… and has dozens of variations with dependencies and libraries that will have various levels of security of their own and potentially more vulnerabilities.
I don’t have the solution, I just don’t see this as fixing anything. What’s the replacement?
clearly the most secure option is to have certificates that are only valid for 30 seconds at a time
Let’s be extra safe. New cert per every request
Ephemeral diffie-hellman is exactly that, it’s part of TLS since I think 1.2
And you still can’t self certify.
It’s cute the big players are so concerned with my little security of my little home server.
Or is there a bigger plan behind all this? Like pay more often, lock in to government controlled certs (already done I guess because they control DNS and you must have a “real” website name to get a free cert)?
I feel it’s 50% security 50% bullshit.
You can absolutely run your own CA and even get your friends to trust it.
Yes you can but the practicality of doing so is very limiting. Hell I ran my own CA for my own internal use and even I found it annoying.
The entire CA ecosystem is terrible and only exists to ensure connections are encrypted at this point. There’s no validation or any sort of authority to say one site is better than another.
But you have to manually accept this dangerous cert in the browser right?
Very interesting actually, do you have any experience about it or other pointers? I might just set one up myself for my tenfingers sharing protocol…
No, because it’s no longer dangerous if it’s trusted.
You give your friends your public root and if applicable, intermediary certs. They install them and they now trust any certs issued by your CA.
Source: I regularly build and deploy CA’s in corps
It’s pretty simple to set up. Generate CA, keep key and other private stuff stored securely, distribute public part of CA to whoever you want and sign all the things you wish with your very own CA. There’s loads of howtos and tools around to accomplish that. The tricky part is that manual work is needed to add that CA to every device you want to trust your certificates.
No that’s the point. If you import the CA certificate on your browser, any website that uses a cert that was signed by that CA will be trusted and accessible without warning.
not all phones support manually adding certs
Which phones. Android and iOS could.
I don’t know about iOS, but Android had support for this in the past. Now the support is partial. It’s no longer possible to install system-level certificates. Or at least they made it extremely inconvenient.
That’s a complaint about those phones not PKI in general then. Though it’s surprising their enterprise support won’t let you since that is (or was) a fairly common thing for businesses to do.
That’s a fair point. However, on the practical side, it’s sad that I would have to root my gf’s phone to let her access the services we host.
I ended up using a DynDNS and Caddy for managing my cert.
Technically something like DANE can allow you to present DNSSEC-backed self-signed certs and even allow multi-domain matching that removes the need for SNI and Encrypted Client Hello… but until the browsers say it is supported, it’s not
At some point there was a browser extension to support DANE (and Perspectives and similar approaches against centralization) but since then, browser vendors fixed that security flaw.
And you still
can’tcan self certify.Skill issue, you’ve always been able to self certify. You just have to know where to drop the self signed cert or the parent/root cert you use to sign stuff.
If you’re running windows, it’s trivial to make a self signed cert trusted. There’s an entire certificate store you can access that makes it easy enough you can double click it and install it and be on your way. Haven’t had a reason to figure it out on Linux, but I expect it won’t be super difficult.
assuming “rest of the industry” in this context refers to ssl seller lobby.
Yes, this requirement comes from the CA/Browser Forum, which is a group consisting of all the major certificate authorities (like DigiCert, Comodo/Sectigo, Let’s Encrypt, GlobalSign, etc) plus all the major browser vendors (Mozilla, Google, and Apple). Changes go through a voting process.
Google originally proposed 90 day validity, but Apple later proposed 47 days and they agreed to move forward with that proposal.
Don’t worry they’ll reduce the cost of certificates proportionally to the longevity of the certificate.
Right? Anybody?
<< Cricket noises >>
Edit: obviously not LE, but other certificate vendors.
DigiCert have said they’re not changing their prices as a result. It’s still a yearly payment (or every 2 or 3 years if you prefer that).
Lol, never had to buy a cert huh?
You’re still buying a year or more at a time, no matter the lifetime of the cert itself. Even if the cert lifetime was a week, you’re still buying the same product, no matter how many times you rotate it.
Personally? No I’ve never bought a cert before. Given there’s free alternatives and it’s a homelab it doesn’t make sense. Otherwise I’ve used them on AWS, where ACM also just provides them for free.
What you’re saying is that certificate providers will still charge you and provide certificates for a year, but just provide you with N certificates to span that year?
E.g. if the duration is 45 days then they will give you 365/45 certificates ?
. if the duration is 45 days then they will give you 365/45 certificates ?
Minimum. We get through digicert at work, and we abuse the hell out of our wildcard and reissue it tons of times a year. You’re buying a service for the year, not an individual cert.
Interesting. Thanks for that insight :)
It’s being deiven by the browsers. Shorter certs mean less time for a compromised certificate to be causing trouble.
https://cabforum.org/working-groups/server/baseline-requirements/requirements/
most trouble is probably caused in the first few days. Doesn’t matter if it’s 45 or 90 days, it would have to be a few hours to be meaningfully short. Given that automating things like this is annoying sometimes, you’ll be sure people will max out the 45 days…
I’m pretty sure it’s the SSL seller lobby just wanting more money, tbh. Selling snake oil security.
Given that automating things like this is annoying sometimes, you’ll be sure people will max out the 45 days…
I know from professional experience that this is a stupid as fuck idea that leads to outages. One of the many reasons I’m working to automate those annoying ones.
Also, don’t let perfect be the enemy of better.
I’m not a capitalist, I don’t care about outages. I can live with Facebook being down for a few days, or my bank not accepting transfers for a day or so. Then again, I grew up with the internet in the 90s and prioritise good software and tools over availability, I guess?
Obviously at my job I have to do what my employer thinks. But if nobody cared I’d definitely do our Gitlab upgrades once a week once they’re out and not in some weird “maintenance window” mandated by SLAs and stakeholders.
I’m pretty sure it’s the SSL seller lobby just wanting more money, tbh. Selling snake oil security.
And selling “certificate automation” tools.
Yeah you can still do a lot of damage in a few hours, but 45 days is a meaningful reduction in exposure time from year+
The five-assed monkey of cert lifetimes.
As useless measures go this will certainly be one; especially while CRLs are a thing.
Coming soon. Daily certs. Just $19.99 a month.
