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)

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.

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.

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.

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.

This seems like a good idea.

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. :/