What is the point of shortening the life time to 45 days?
Why not 60 seconds? That's way more secure. Everything is automated after all, so why risk compromised certificate for such a long period, like 45 days?
Or how about we issue a new certificate per request? That should remove most of the risks.
While I believe you're posting questions out of frustration rather than genuine curiosity, I think it's worth pointing out two things.
One: most of the reasoning is available for reading. Lots of discussion was had. If you're actually curious, I would suggest starting with the CA/B mailing group. Some conversation is in the MDSP (Mozilla's dev-security-policy) archives as well.
Two: it's good to remember that the competing interests in almost every security-related conversation is the balance between security and usability. Obviously, a 60-second lifetime is unusable. The goal is to get the overlap between secure and usable to be as big as possible.
serious q: maybe not 60 sec, but why 45 days instead of ~1 day or even hours? at 45 days, it pretty much has to be automated.
Our internal CAs run 72 hour TTLs, because we figured "why not" 5-6 years ago, and now everyone is too stubborn to stop. You'd be surprised how much software is bad at handling certificates well.
It ranges from old systems like libpq which just loads certs on connection creation to my knowledge, so it works, down to some JS or Java libraries that just read certs into main memory on startup and never deal with them again. Or other software folding a feature request like "reload certs on SIGHUP" with "oh, transparently do listen socket transfer between listener threads on SIGHUP", and the latter is hard and thus both never happen.
45 days is going to be a huge pain for legacy systems. Less than 2 weeks is a huge pain even with modern frameworks. Even Spring didn't do it right until a year or two ago and we had to keep in-house hacks around.
Honest reply: because the infrastructure isn't ready to support 1-day certificates yet. If your cert is only valid for one day, and renewal fails on a Saturday, then your site is unusable until you get back to work on Monday and do something to fix it. There are things that can be done to mitigate this risk, like using an ACME client which supports fallback between multiple CAs, but the vast majority of sites out there today simply aren't set up to handle that yet.
The point of the CA/BF settling on 47-day certs is yes, to strongly push automation, but also to still allow time for manual intervention when automation fails.
The 7-day certificate will be here before you know it [1].
[1]: https://letsencrypt.org/docs/profiles/#shortlived
They are not sadists, contrary to what others say in the comments.
Although for the benefit of masochists, they are going to offer 6 day certs as an option soon.
Yep, the "shortlived" (6-day) profile will be available to the general public later this week. But at this time we explicitly encourage only mature organizations with stable infrastructure and an oncall rotation to adopt that profile, as the risks associated with a renewal failing at the beginning of a holiday long weekend are just too high for many sites.
asynchronous revocation check would be far superior option; I'm sad industry abandoned trying to make it work.
The article does link in multiple places to another article discussing why revocation checks do not work for privacy (you're telling someone your browsing history basically) and reliability (what if the CA's revocation checker goes down?) reasons.
[flagged]
Could have just kept using OSCP stapling
Basically OCSP stapling (more specifically must-staple) is isomorphic to short-lived certificates.
OSCP enables every website someone visits to be tracked; see https://news.ycombinator.com/item?id=46290033
OSCP stapling (which OP mentions) is supposed to fix that though.
You know that the original idea was to drop it to 17 days?! And i think that is still on the books.
To be honest, the issue is not the time frame, you can literally have certs being made every day. And there are plenty of ways to automated this. The issue is the CT log providers are going to go ape!
Right now, we are at 24B certificates going back to around 2017 when they really started to grow. There are about 4.5B unique domains, if we reduce this to the amount of certs per domain, its about 2.3B domain certs we currently need.
Now do 2.3B, x 8 renewals ... This is only about 18,4B new certs in CT logs per year. Given how popular LE is, we can assume that the actual growth is maybe 10B per year (those that still use 1 year or multi year + the tons of LE generated ones).
Remember, i said the total going back to 2017 currently is now only 24B ... Yea, we are going to almost double the amount of certs in CT logs, every two years.
And that assumes LE does not move to 17 days, because then i am sure we are doubling the current amount, each year.
Good luck as a CT log provider... fyi, a typical certificate to store is about 4.5kb, we are talking 45TB of space needing per year, and 100TB+ if they really drop it down to 17 days. And we did not talk databases, traffic to the CT logs, etc...
Its broken Jim ... Now imagine for fun, a daily cert, ... 1700TB per year in CT log storage?
A new system will come from Google etc because its going to become unaffordable, even for those companies.
Have you heard the good news of Merkle Tree Certificates[1,2]? They include the transparency cryptography directly in the certificate issuance pipeline. This has multiple benefits, one of them being way smaller transparency logs.
1: https://www.youtube.com/watch?v=uSP9uT_wBDw A great explainer of how they work and why they're better.
2: https://davidben.github.io/merkle-tree-certs/draft-davidben-... The current working draft
Yep ... Saves about 40%, seen one of the implementations. One of the guys posting here from time to time has a working version.
I am a CT log operator and I hands down support short-lived certificates. Automation and short lifetimes solve a lot of the pain points of the WebPKI.
We can solve the storage requirements, it’s fine.
Is there a big use case for permanent CT logs of long-expired certificate?
Tons of information for research, hackers, you name it ... It shows a history of domains, you can find hidden subdomains, still active, revoked etc ...
Do not forget that we had insane long certificates not that long ago.
The main issue is that currently you can not easily revoke certs, so your almost forced to keep a history of certs, and when one has been revoked in the CT logs.
In theory, if everybody is forced to change certs every 47 days, sure, you can invalidated them and permanently remove them. But it requires a ton of automatization on the user side. There is still way too much software that relies on a single year or multi year certificated that is manually added to it. Its also why the fadeout to 47 days, is over a 4 year time periode.
And it still does not change the massive increased in requests to check validation, that hits CT logs providers.
> Tons of information for research, hackers, you name it ... It shows a history of domains, you can find hidden subdomains, still active, revoked etc ...
You can store that kind of information in a lot less space. It doesn't need to be duplicated with each renewal.
> The main issue is that currently you can not easily revoke certs, so your almost forced to keep a history of certs, and when one has been revoked in the CT logs.
This is based on the number of active certificates, which has almost no connection with how long they last.
> There is still way too much software that relies on a single year or multi year certificated that is manually added to it.
Hopefully less and less going forward.
> And it still does not change the massive increased in requests to check validation, that hits CT logs providers.
I'm not really sure how that works but yeah someone needs to pay for that.
Where did you get 17 days from?
There was talking going on in one of the CA/Browser Forum regarding certificate expirations, and how they looked at potentially 17 days. The 45 days was a compromise, but the whole 17 days was never removed from the table, and was still considered as a future option.
Honestly don't recall discussing 17 days, but I could be wrong. 47 days was a 'compromise' in that it's a step-down over a few years rather than a single big-bang event dropping from 397->90/47/less.