The push for shorter and shorter cert lifetimes is a really poor idea, and indicates that the people working on these initiatives have no idea how things are done in the wider world.
These changes are coming from the CAB forum, which includes basically every entity that ships a popular web browser and every entity that ships certificates trusted in those browsers.
There are use cases for certificates that exist outside of that umbrella, but they are by definition niche.
Hardly 'by definition niche' IMHO.
So great for E-Commerce, not so great for anyone else.
So no one that actually has to renew these certificates.
Hey! How long does a root certificate from a certificate authority last?
10 to 25 years?
Why don't those last 120 minutes? They're responsible for the "security" of the whole internet aren't they?
In another comment someone linked to a document from the Chrome team.
Here’s a quote that I found interesting:
“In Chrome Root Program Policy 1.5, we landed changes that set a maximum ‘term-limit’ (i.e., period of inclusion) for root CA certificates included in the Chrome Root Store to 15 years.
While we still prefer a more agile approach, and may again explore this in the future, we encourage CA Owners to explore how they can adopt more frequent root rotation.”
https://googlechrome.github.io/chromerootprogram/moving-forw...
I believe google, who maintain chrome and are on the CAB, are an entity well known for hosting various websites (iirc, it's their primary source of income), and those websites do use https
I am not kidding, but also the rest of your comment isn’t at all related to what I said.
Nobody is being forced to use 6-day certs for domains though, when the time comes Let's Encrypt will default to 47 days just like everyone else.
Yet
The people who innovate in security are failing to actually create new ways to verify things, so all that everyone else in the security industry can do to make things more secure is shorten the cert expiration. It's only logical that they'll keep doing it.
In your answer (and excluding those using ACME): is this a good behavior (that should be kept) or a lame behavior (that we should aim to improve) ?
Shorter and shorter cert lifetime is a good idea because it is the only way to effectively handle a private key leak. Better idea might exist but nobody found one yet
Thing is, NOTHING, is stopping anyone from already getting short lived certs and being 'proactive' and rotating through. What it is saying is, well, we own the process so we'll make Chrome not play ball with your site anymore unless you do as we say...
The CA system has cracks, that short lived certs don't fix, so meanwhile we'll make everyone as uncomfortable as possible while we rearrange deck chairs.
awaiting downvotes in earnest.
(The classic problem with self-signed certs being that TOFU doesn’t scale to millions of users, particularly ones who don’t know what a certificate fingerprint is or what it means when it changes.)
Though if I may put on my tinfoil hat for a moment, I wonder if current algorithms for certificate signing have been broken by some government agency or hacker group and now they're able to generate valid certificates.
But I guess if that were true, then shorter cert lives wouldn't save you.
TLS certs should be treated much more akin to SSH host keys in the known hosts file. Browsers should record the cert the first time they see it and then warn me if it changes before it's expiration date, or some time near the expiration date.
Obviously you might still be victim #1 of such a scheme... But in general the CA's now aren't really trusted anymore - the real root of trust is the CT logs.
the ENTIRE reason the short lifetime is used for the LE certs is that they haven't figured out how to make revoking work at scale.
Now if you're on latest browser you might be fine but any and every embedded device have their root CAs updated only on software update, which means compromise of CA might easily get access to hundreds of thousands devices.
And 200 is not "at scale". The list of difficulties in revoking roots is a very different list from the problem you're citing.
> any and every embedded device
Yes it's flawed but it's so much better than the previous nothing we had for detecting one of the too-many CAs going rogue.
This is great, and actually constructive!
I use, a hack i put together http://www.jofla.net/php__/CertChecker/ to keep a list (in json) of a bunch of machines (both https and SSH) and the last fingerprints/date it sees. Every time it runs i can see if any server has changed, just is a heads-up for any funny business. Sure its got shortcommings, it doesnt mimmic headers and such but its a start.
It would be great if browsers could all, you know, have some type of distributed protocol, ie DHT where by at least some concensus about whether this cert has been seen by me or enough peers lately.
Having a ton of CAs and the ability to have any link in that chain sing for ANY site is crazy, and until you've seen examples of abuse you assume the foundations are sound.
Probably not. For browsers to accept this certificate it has to be logged in a certificate transparency log for anyone to see, and no such certificates have been seen to be logged.
This makes sense from a security perspective, insofar as you agree with the baseline position that revocations should always be honored in a timely manner.