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

101–110 of 115 posts

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

#101

Post by soco »

sam_lowry_ wrote: post #99
soco wrote: post #97

Earlier quoted context omitted.

I wish you good luck in court trying to get compensation for the damage you've got through a JS injection attack. Because people prefer to lock their valuables instead of constantly having to identify and sue thieves.

Not court, regulation. Wanna be a carrier? Then don't meddle with traffic. Otherwise, you are liable for all the child porn and drug trade that happen to cross your boundary.

Right, we actually agree on this. And where is regulation enforced? In courts. Who says the provider is liable? A court. This was my point: not locking your house means a lot of processing to get back to the place where you have been before - if it can ever happen. And I'd very much not go through a whole trial...

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

#102

Post by Natfan »

sam_lowry_ wrote: post #99
soco wrote: post #97

Earlier quoted context omitted.

I wish you good luck in court trying to get compensation for the damage you've got through a JS injection attack. Because people prefer to lock their valuables instead of constantly having to identify and sue thieves.

Not court, regulation. Wanna be a carrier? Then don't meddle with traffic. Otherwise, you are liable for all the child porn and drug trade that happen to cross your boundary.

am i a carrier when i host my own wifi network?

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

#103

Post by sam_lowry_ »

soco wrote: post #101
sam_lowry_ wrote: post #99

Earlier quoted context omitted.

Not court, regulation. Wanna be a carrier? Then don't meddle with traffic. Otherwise, you are liable for all the child porn and drug trade that happen to cross your boundary.

Right, we actually agree on this. And where is regulation enforced? In courts. Who says the provider is liable? A court. This was my point: not locking your house means a lot of processing to get back to the place where you have been before - if it can ever happen. And I'd very much not go through a whole trial...

Regulation is enforced in courts only in the US, heh.

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

#105

Post by lambdaone »

bruce511 wrote: post #41
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…

But it's only the extreme warning that alerts the website (usually via a customer complaining) that the cert hasn't been renewed. Having the lesser warning just kicks the can down the road. 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.

What might be better is to, in addition to failing hard when the certificate expires, web browsers were to give a 'soft' click-through user warning if the certificate on the site - while still within its validity period - has less than say 7 days to go before expiry.

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.

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

#106

Post by hdgvhicv »

jzl wrote: post #87
hdgvhicv wrote: post #68

Earlier quoted context omitted.

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

> While it hasn't really taken off outside of Firefox

Thus doesn’t really work. Sadly.

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

#107

Post by icedchai »

dijit wrote: post #92
naturalmovement wrote: post #90

Earlier quoted context omitted.

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

> competent system administrators Sorry, we don't hire those anymore. Best I can do is a YAML monkey who knows how to glue cloud services together..

So true. The last time I worked with a person with an actual "system administrator" title was 2009!

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

#108

Post by po1nt »

anal_reactor wrote: post #88
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.

In theory this sounds great, but you only realize how much do you rely on a single point of failure, once it fails. Just see github outages or even electricity outages at your home.

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

#109

Post by po1nt »

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…

If you couldn't switch, that would be a monopoly. But single point of failure is when you put all your fruit in one basket. Airplanes have redundant systems, even though you can always buy new components. But it's much harder to change them mid-flight.

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

#110

Post by po1nt »

doublerabbit wrote: post #85
gsliepen wrote: post #84

Earlier quoted context omitted.

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.

Just picture the massive load spikes on other SSL providers in that moment. And the fact that even those might not work, as their backends might rely on LE SSL 3rd party services for ID checking or something.
Post reply on HN