Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Encrypt had a higher error rate for 90 minutes today

letsencrypt.status.io

Post reply on HN
Print view View original

81–90 of 115 posts

Re: Let's Encrypt had a higher error rate for 90 minutes today

#81

Post by hannob »

dlcarrier wrote: post #23

That explains why one of my IoT vendors is using an expired certificate. 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. Y…

There are reasons browsers do things the way they do.

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.

Re: Let's Encrypt had a higher error rate for 90 minutes today

#83

Post by sam_lowry_ »

cpach wrote: post #82
sam_lowry_ wrote: post #77

Earlier quoted context omitted.

Thank them for making the web depend on a single US-based shady org, as if DNS was not enough.

Feel free to launch your own CA.

No-no, I would rather go back to the good old HTTP/1.1.

P.S. JS injection into TCP packets and other meddling with passthrough data should be banned legally, not technically via encryption.

Re: Let's Encrypt had a higher error rate for 90 minutes today

#84

Post by gsliepen »

po1nt wrote: post #75

Let's encrypt is a single point of failure for a large percentage of the internet.

No, it's not. You can always switch to a different SSL provider. There are other free ones (as mentioned in other comments).

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.

Re: Let's Encrypt had a higher error rate for 90 minutes today

#85

Post by doublerabbit »

gsliepen wrote: post #84
po1nt wrote: post #75

Let's encrypt is a single point of failure for a large percentage of the internet.

No, it's not. You can always switch to a different SSL provider. There are other free ones (as mentioned in other comments). 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 clie…

Nothing is a point of failure if you can switch but that's not really true unless you have fail-over.

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.

Re: Let's Encrypt had a higher error rate for 90 minutes today

#86

Post by arcfour »

tgsovlerkhgsel wrote: post #63
mannyv wrote: post #56

Earlier quoted context omitted.

Certificate expiry is less severe than an untrusted issuer or a host mismatch. 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?

Revocation information may not be available for expired certificates. Not that it matters much because the last time I checked revocation didn't really work for non-expired certificates either, but I think that (+ the risk of people treating expired certificates as worthless and thus increasing the risk of exposure) is the main reason. Also of course domains changing owners, but again... I don't think we have good mo…

CRLs mostly still work for revoking non-expired certificates. They're a bit clunky, but they don't have to be: https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...

Re: Let's Encrypt had a higher error rate for 90 minutes today

#87

Post by jzl »

hdgvhicv wrote: post #68
notrealyme123 wrote: post #46

Earlier quoted context omitted.

I think revoking them would be better in such a case.

Revoking doesn’t really work. https://garantir.io/certificate-revocation-challenges-and-be...

Stale news. Mozilla introduced a new solution for certificate revocation that solves nearly all the problems with old methods. While it hasn't really taken off outside of Firefox, that's mostly because Google and Apple haven't embraced it because they are too busy trying to shorten certificate life unnecessarily.

https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...

Re: Let's Encrypt had a higher error rate for 90 minutes today

#88

Post by anal_reactor »

po1nt wrote: post #75

Let's encrypt is a single point of failure for a large percentage of the internet.

Hot take, but in general single points of failure are less of an issue than it seems because usually outages simply aren't that common. Meanwhile maintaining whole infrastructure to avoid single point of failure is often very expensive.

Re: Let's Encrypt had a higher error rate for 90 minutes today

#89

Post by naturalmovement »

hdgvhicv wrote: post #68
notrealyme123 wrote: post #46

Earlier quoted context omitted.

I think revoking them would be better in such a case.

Revoking doesn’t really work. https://garantir.io/certificate-revocation-challenges-and-be...

Revocation doesn't work because a cabal of arrogant Googlenos and friends decided it's too hard to fix so we won't do it at all.

The last browser where revocation worked properly is Internet Fucking Explorer.

Re: Let's Encrypt had a higher error rate for 90 minutes today

#90

Post by naturalmovement »

flakes wrote: post #69
notrealyme123 wrote: post #46

Earlier quoted context omitted.

I think revoking them would be better in such a case.

One is not really better, you want both. Certificate revocation lists are loaded out of band and depending on the client can be poorly enforced. 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.

> Questions come up: do you block a request if you fail to download the latest CRL? How often do you refresh it?

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.

Post reply on HN