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.
The five-assed monkey of cert lifetimes.
As useless measures go this will certainly be one; especially while CRLs are a thing.
Shit like this is why building websites is no longer fun for me like it was back in the 90s and 2000s. There’s way too much security shit to worry about now.
“You can set up your own email server at home, for fun!”
– The 90’s, Probably.
Lol. I’m kinda sad I missed out on that expressive time of making websites when I was growing up. You’re right, now everything is very homogenized and there’s a billion botswarms just waiting for you to be 3 seconds late to a security update so they can zombify your site for…
(Flips papers) Crypto somehow… it’s always crypto.
Internet crime isn’t even cool anymore. Lol
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.
Make no mistake: this is an improvement.
There are substantial unsolvable issues with long lived certificates, and automatic deployment of very short lived certificates is the way to solve them.
Plan for certificate validity of six days in a few years.
Wait, how’s this worse? This makes the Internet safer by reducing the window a leaked key can do harm.
Let’s all just start self signing in protest
Automated certificates are relatively new and pretty neat. Killing off the certificate cartels is an added bonus.
Yeah, I think Letsencrypt (and others) are one of the best things to happen for the internet.
You used to have to cough up a good chunk of monies for a certificate.
Now it’s easily accessible and you (i) never have to think about it after the first setup because a robot automatically renews expiring certificates for me.
Generally this is one of the best improvements: a more secure web that is easier to achieve.
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 …
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.
Just let me know so I can change my crontabs.
I still think the web would have been better off if certificates were signed and part of a web of trust like in GPG/PGP. It wouldn’t stop sites from using trusted CAs to increase their trust levels with browsers, but it would mean that tiny websites wouldn’t need to go through layers of mandatory bullshit and inconvenience. Also means that key signers could have meaningful business relationships rather than being some random CA that nobody has a clue about.
3 letter organisms: NSA - CIA. People tend to think that as conspiracy theory… Even though we have so many real life examples about how the US and the 3 letters agencies have their hands all over the web and privacy and encryption is just a wet dream !
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.
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.
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.
That’s a lot easier said that done for hobbyists that need a certificate for their home server. I will give you a real world example. I run Ubuntu Linux (but without snaps) on my main desktop machine, however like the person you replied to I am old and I don’t have a good memory so when I do use Linux I try to take the easiest approach possible. But I also have a server running on a Raspberry Pi, and another family member (that has a Mac) that I exchange XMPP-based instant messages with. The server runs Prosody, and on my Ubuntu box I run Gajim (the one from the apt repository which is version 1.8.4, I have no idea why they won’t put a newer version in the repo). The other family member uses some MacOS-based XMPP client. The problem is that if there is not a valid certificate on the server, Gajim refuses to send or receive anything other than plain-text messages. It won’t sent or receive files or pictures, etc. unless the certificate is valid.
However the Raspberry Pi does other things as well (it would be silly to dedicate a Pi to just running Prosody) and one of those other things puts a pseudo-web server of sorts on port 80, which is only accessible from the local network. So I can’t use Certbot because it insists on being able to connect to a web server. Even if I had a general web server on the Pi, which I don’t have and don’t want, it would be restricted for local access only. Also, I’m not paying for a DNS address for my own home server. What I found I could do is get a DuckDNS address (they are free) and use that to get a LE certificate. But the procedure is very manual and kind of convoluted, you have to ssh into the server using two separate sessions and enter some information in each one, because of the absolutely asinine way LE’s renewal process works if you don’t have a web server. I hate doing it every 90 days and if I have to do it every 45 days I’ll probably just give up on sending and receiving files.
I should also mention that it took me hours to figure out the procedure i am using now, and it seems so stupid because I have that server locked down with two firewalls (one on the router and then iptables on the server) I don’t even want a certificate but the designers of Gajim in their infinite wisdom(?) decided not to give users the option to in effect say “I trust this server, just ignore an expired or missing certificate.” And the designers of LE never seemed to consider that some people might need a certificate that are not running a web server (and don’t want to run one) and provide some automatic mechanism for renewing in that situation. And just because someone uses Linux does not mean we are all programmers or expert script writers. I can follow “cookbook” type instructions (that is the ONLY way I got Prosody set up) but I can’t write a script or program to automate this process (again, I’m OLD).
I know somebody’s going to be tempted to say I should use some other software (other that Prosody or Gajim). I tried other IM clients and Gajim is the only one that works the way I expect it to. As for Prosody, I have from time to time tried setting up other XMPP servers that people have suggested and could never get any of them to work. As I said, had I not found “cookbook” type instructions for setting up Prosody I would probably not be running that either, it was a PITA to get working but not that it IS working I don’t want to go through that again. And Prosody isn’t the problem, it works perfectly fine without a valid certificate, but pretty much every Linux IM client I have tried either loses functionality or won’t work at all if the server doesn’t have a valid certificate. And no I don’t run or use Docker, nor do I have any desire to (especially on a Raspberry Pi).
EDIT: After giving this some thought I decided look further into this, and discovered that while Certbot can’t handle this, it’s possible that a script called acme.sh can. See https://github.com/acmesh-official/acme.sh?tab=readme-ov-file (also https://github.com/acmesh-official/acme.sh?tab=readme-ov-file#8-automatic-dns-api-integration - may need to scroll up just a bit, the pertinent item is “8. Automatic DNS API integration”). I haven’t tried it yet (just manually renewed yesterday) but it looks promising if I can figure it out. Thought I’d post the links for anyone else that might be in the same situation.
That’s a lot easier said that done for hobbyists that need a certificate for their home server.
I’d you’re going to self host you need to learn. I have no time for kids who just want “Google but free” and don’t want to spend any time learning what it takes to make that happen.
we shouldn’t need to pay for a domain to be able to self host.
You don’t need to if you’re just using things locally.
But also - domains are cheap.
yes you need if you want HTTPS that is accepted by the smartphone client apps of your services.
domains are a constant expense
They’re cheap. You can also generate your own certs and use your own ca. But otherwise yes - quit yer bitching and learn how to do things right.
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
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.
The current automation guidelines and defaults renew certs 30 days from expiry. So even today certs aren’t around for more than 60 days, it’s just that they’re valid for 90.
Additionally you can fairly easily monitor certs to get an alert if you drop below the 30 day threshold and automatic cert renewal hasn’t taken place.
I use Grafana self hosted for this with their synthetic monitoring free tier but it would be relatively trivial to roll your own Prometheus-exporter to do the same.
I doubt they will drop below 1-2 weeks. Any service outage would turn into a ddos when service was restored.
This is typically called a thundering herd
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.
Ah yeah, those were interesting times. (Although there were some historically interesting viruses back in the day for those floppies too)
Fond memories though. Learning basic on a cartridge… Using literal cassettes for storage. That horrifying sound of a 5" floppy drive struggling to read that file you really needed. Good times.
Generally speaking that was probably what most of us would identify as pre internet times - but usenet / BBS / and early internet and prior definitely was more bright eyed and optimistic. Probably because it was more about learning and tech and less about monotizing every square inch of your existence 😂
You can already get 6-day certificates if you want to https://letsencrypt.org/2025/01/16/6-day-and-ip-certs
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. :(
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.
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
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.
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.
“when i get to it” is my time frame aswell, till then its a reoccurring calendar notification with instructions because past me who set this all up was a genius compared to sleep deprived current me
I definitely know that feeling.
Now that I’m at a keyboard, here’s the (Caddy) plugin I was referring to : https://github.com/caddy-dns/namecheap
Isn’t this just CRL in reverse? Part of the point of cryptographically signing a cert is so you don’t have to do this if you trust the issuer.
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.
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.
Fair enough lol, can’t argue with that.
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
Essentially, renew the certificates once per month, with some buffer time in case of issues.
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.
Oh, I’m really just pining for the days before the ‘Eternal September’, I suppose. We can’t go back, I know. :/
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…
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.
YES! Keep cutting it down!
Revocation is a lost cause and if you don’t automate you deserve what you get.
I have multiple self hosted services at home which are impossible to automate because they are not accessible from the internet without VPN. And some even don’t have internet access. Still me and my roommates are using them through a valid domain that points to the local address enabling https. Some services require https to function at all. After log4j i’ll never again open a “normal” port 80 or 443 to my local net. So thanks i guess. 90 days was annoying already. Great it works out for you
Dude, you need to figure out a way to automate that. It’s no way to live.
I agree, but it’s impossible to convince my less tech savy roommates and friends to let me install a root certificate. “That sounds like i could read all their private messages”, lol. Just let me have my certificate for https in my local net. I don’t need to be “even more” secure. I get that that’s necessary for public services, but surely not for local selfhosting. I don’t even have a port open other than wireguard. And i would not even care “if a roommate hacks/gets access to a guests voice commands for home assistant.” (Not complaining at you but at this trend. I do think my use case is valid)
You are gonna laugh if i tell you how i partly automated this workaround. A script changes the (dyn) dns entries of all subdomains to point to my public server in a datacenter. There, it ssh’s in and requests the certificates with certbot. Then, it restores the dns entries and downloads and installs the certificates in the local net. Still requires manual supervision and sometimes intervention. My domains do not support automated dnssec. I don’t have time to secure my local net enough to feel good about opening ports. If all certificate lifetimes get shorter, i’ll either have to switch my domain provider or give up selfhosting for other people.
Allowing a certificate without proper validation for local only networks is a terrible, terrible idea. I could super easily use this as a loophole to set up a honeypot public free wi-fi, redirect all traffic through a reverse proxy and man-in-the-middle every single HTTPS connection, effectively allowing me to harvest everyone’s passwords in a really quick and easy way.
Just use DNS verification. It’s not that hard.
Use DNS validation
Can you not issue your own certificate? I guess it depends on how many devices and what types of devices need to connect. It’s be a one time effort per device (importing your own self signed cert) versus one time effort per service per X days.
I did that for myself a few years back. But i can’t convince my roommates, let’s not even speak of guests, to install a (my) root certificate. My android phone still complains about “possibly supervised network traffic” since back when i installed my root ca. Maybe there is another solution im not aware of, but i can’t think of any
It’s so infuriating to me that there isn’t a way to just encrypt traffic without verifying it’s part of a chain. By all means, give a nag warning in browsers, but ugh, I think that ship has long since sailed. Plus, realistically, you’d need just as many scary warnings to deter the average user that they might be getting MITMed.
The solution is to not use Http based validation of the cert, but use dns based validation. Possibly combined with a wildcard cert for your whole domain. This is what I do for internal services on my LAN, along with split DNS so that the internal services aren’t even listed in public DNS.
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
Well it should be as short as possible while still being practical. LE doesn’t have infinite server compute, renewal also takes some amount of time, plus if they make the validity too short people might stop using them (pretty evident judging from sentiment here) and move to other CAs and make what they do pointless.
45 days are still plenty of time yet people are already complaining. Does make me worry.
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
Just saying:
There are alternatives for LE,not for all things, but for a lot. Afaik not all of them do follow suit.
Just skip to the point and make it 1 day
the whole point is to not break the internet. slow is fine
Coming soon. Daily certs. Just $19.99 a month.
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.
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 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.
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, 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
Thank you!
Is there some simple soft that let you make those certs, like with a root cert and then “derived” certs? On linux :-) ?
I guess people have to re-trust every now and then because certs get old, or do they trust the (public partof the) root cert and the daughter certs derived from root are churned out regularly for the sites?
Openssl can do everything.
That’s right, but instead of the word derived we use “issued”
Correct certs get old by design, they can also be revoked. As another commenter mentioned the biggest pain is actually in the redistribution of these end certificates. In enterprise this is all managed usually with the same software they use for deployment or have auto enrollment configured.
You should find tons of guides just take it slow to understand it all. Understanding certificates in depth is a rare and good skill to have. Most sysadmins I come across are scared to death of certificates.
I was forced to learn some of it at work (using and signing medical payment transactions, with x509 certificates) so I have ar least a starting point. I have no idea how the revoke process works though, I can’t figure out a way that it functions without a central authority getting queried regularly. I thonk I can start without that knowledge though.
Anyway, with your information I’m up and running, thank you again!
“Derived certificates” not child certs, noted !
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.
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.
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?
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.
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)
