Let's Encrypt had a higher error rate for 90 minutes today(letsencrypt.status.io) |
Let's Encrypt had a higher error rate for 90 minutes today(letsencrypt.status.io) |
It seems our status.io notes are being misinterpreted as much more severe than they were intended to reflect.
Edit: Note that this was written in response to a previous submission title implying that Let's Encrypt was entirely down most of the day.
Edit: my bad. I’ve tried as well recently, when you’re rushing to get your new domain up of course…
I wish Firefox would just give a mild warning for a recently expired certificate, instead of treating it the same as a true man-in-the-middle attach. It's not like someone who couldn't factor the private key in 200 days could in 201 days or even 300 days.
I'm convinced that we'd have better security, if we didn't have so much security theater. You'd think TLS is useless, from the warning my phone gives if I connected to a public Wi-Fi AP, but then again there's nothing in TLS (or WPA) that prevents it from being used in a way that is completely useless: https://www.youtube.com/watch?v=M1si1y5lvkk
I don't think so. There was a dip in success rates for 90 minutes today, but nobody should be renewing their certificate within 90 minutes of expiration. If you're at that point, something went wrong weeks ago.
You obviously haven't worked with hardware guys.
"I mean, what's the point of those last 30 days if you need to renew it 30 days before expiration? Why not just renew it before it expires? If I'm required to renew it 30 days before the expiration date then the expiration date is a lie, isn't it?"
How long do you think a certificate lives?
Nope, if the SSL industry continues to insist on increasingly short cert lifetimes then I want Firefox to give no quarter when a cert expires.
Play by their rules and fall by their rules too.
The former is most likely an administrative error (ie: someone forgot to renew, or the auto-renew is failing). The latter is more likely to be an MTM attack.
I'm not sure how you would use an expired cert as an attack vector. By loading in an old cert into an expired domain so you could spoof older content?
Experience and user studies have shown that users have a hard time decoding what error messages mean. "This certificate is expired, but only for a little while" isn't meaningful for people who don't have a mental model of what a certificate is.
Furthermore, "downgrading" warnings increases the incentive to ignore issues, potentially causing more problems down the line.
The IoT should have updated the certs weeks in advance. If they haven't done it by day 0 then their process is broken and delaying the scary warning to say day +5 won't solve anything.
That's probably long enough for most companies to be alerted to the problem in time and to get their act together to fix the problem.
If anyone is renewing certificates with less than a day remaining, that's an issue on their end far more than anything else.
ref: https://www.reuters.com/article/world/millions-of-websites-o...
> Some clients may encounter 400 and 500 error responses.
Requirements: free, available to everyone, automation friendly, issues certificates that are actually considered trustworthy by other parties.
Google Trust Services – free ACME certs, requires a Google account for registration
SSL.com Free DV SSL – offers free 90-day certs through ACME
It seems a bit silly that a service that could be forced by EO to revoke foreign certificates is the backbone of so much of the internet.
It's a bit mathy, but if you can make it through that, I highly recommend watching the whole video, especially if you like dad jokes.
None. Big tech intentionally made Let's Encrypt a single point of giant failure.
> And in case none exists, what does it take to build one?
A new Internet and Web standards stack. The whole problem is self-imposed -- we could have published self-signed Ed25519 keys on the DNS instead, and the result would be more secure than whatever it is we have now.
Let's Encrypt is incredible.
However, thinking about how to make your own setup more robust without having to manually change configuration when one SSL provider stops working is a good exercise. I wonder if you can just get your server's private key signed by multiple SSL providers, and serve multiple certificates to clients, and whether all browsers handle that correctly.
If LE was to go nope right now, how fast could you move your stack from LE?
You can't use multiple SSL certificates as redundancy. You could probably create something bespoke with a Load Balancer and SSL offloading but that's just more overhead for really nothing.
Expiry is a pretty fundamental part of the security model of certificates.
Also of course domains changing owners, but again... I don't think we have good monitoring for that during the current long lifetime, so maybe a grace period where a warning is shown but it's easier to click through would be a good idea. Perhaps combined with a requirement to keep revocation information (and keep revoking expired certificates) X days past expiry.
If you're one of the few early adopters of short-lived (6-day) certs you should renew at 3 days, giving you 3 days for a successful renewal. A 90 minute outage, even if it was a full outage, would not interfere with a successful renewal.
Many countries won't let you enter if your passport expires less than 6 months after your planned departure date. Basically the effective validity of a passport is 0.5 years less than the period you pay for.
I haven't had one in 20 years, which kinda proves my point.
Questions come up: do you block a request if you fail to download the latest CRL? How often do you refresh it?
When the cert expires, it can be removed from the CRL, so shorter lived certs will allow CRLs to be smaller and faster to transfer.
In the before times we left settings like this up to competent system administrators to decide based on risk and not hardcoded by a handful of people at Google.
https://garantir.io/certificate-revocation-challenges-and-be...
https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...
The last browser where revocation worked properly is Internet Fucking Explorer.
Thus doesn’t really work. Sadly.
P.S. JS injection into TCP packets and other meddling with passthrough data should be banned legally, not technically via encryption.