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

91–100 of 115 posts

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

#91

Post by bluesign »

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…

What you want is warning when certificate expiry in next 7 days, then everyone would update before the warning.

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

#92

Post by dijit »

naturalmovement wrote: post #90
flakes wrote: post #69

Earlier quoted context omitted.

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.

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

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

#93

Post by zx8080 »

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

What is the reason that they are shortening it?

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

#94

Post by zelphirkalt »

xarope wrote: post #44
saagarjha wrote: post #9

Earlier quoted context omitted.

I see you are unfamiliar with status page-ese. “Degraded performance” is a term which means some form of “the entire datacenter is probably on fire”.

That would a Microsoft'ese, "Some regions are encountering issues" => "The entire world is down, but our status page is working"

I also see that fitting into the corporate language of Gaslightese.

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

#95

Post by dxdm »

Kesseki wrote: post #76
dxdm wrote: post #73

Earlier quoted context omitted.

Using only color to communicate the status is confusing. If you want to communicate something, it's often best to just say it. The color can be a visual reinforcement of that. Then your explanation would not be needed.

We do say it. That's what the "Incident Status" field is there for.

But that's not were the confusion is created. I don't even see the status field on mobile without scrolling. You don't have a missing status field, you have too much confusion, because the field and/or the color have a placement mismatch.

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

#96

Post by greatgib »

Kesseki wrote: post #5

To be clear, “Degraded Performance” means just that, not “down.” Let’s Encrypt’s issuance is mostly working fine.

They claim "Degraded Performance", but 400 and 500 error responses is a non fully working service and not a performance that is just "less good".

> Some clients may encounter 400 and 500 error responses.

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

#97

Post by soco »

sam_lowry_ wrote: post #83
cpach wrote: post #82

Earlier quoted context omitted.

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.

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.

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

#98

Post by RetroTechie »

tonyhart7 wrote: post #18
saagarjha wrote: post #4

Seems not ideal for an entity who seems to be pushing for shorter expiration periods all the time

isn't this the other way around ??? because shorter expiration time resulting on more issuing cert and therefore make it more prone to downtime

And perhaps more opportunities to insert bad certificate somehow.

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

#99

Post by sam_lowry_ »

soco wrote: post #97
sam_lowry_ wrote: post #83

Earlier quoted context omitted.

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.

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.

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

#100

Post by icedchai »

otabdeveloper4 wrote: post #21
pibaker wrote: post #6

What are the viable alternatives to LE? And in case none exists, what does it take to build one? Requirements: free, available to everyone, automation friendly, issues certificates that are actually considered trustworthy by other parties.

> What are the viable alternatives to LE? 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.

Do you remember the early days of SSL certificates? It took an act of god just to get a certificate: verification rituals like faxing corporate paper work, phone calls, manually reissuing certs because someone forgot the "www", forgotten renewals...

Let's Encrypt is incredible.

Post reply on HN