Live data from Hacker News

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

letsencrypt.status.io

61–70 of 115 posts

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

#61
post #54

Earlier quoted context omitted.

Since Let's Encrypt wasn't down most of the day if would be helpful if you could update the title to reflect that.

I updated the title. Let me know if you think it's more accurate. It did appear as down for me though.

Yeah, thanks

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

#62
post #56

Earlier quoted context omitted.

> I wish Firefox would just give a mild warning for a recently expired certificate 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.

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?

If a key is breached, the certificate can be revoked, but that revocation goes away once the certificate is expired.

Expiry is a pretty fundamental part of the security model of certificates.

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

#63
post #56

Earlier quoted context omitted.

> I wish Firefox would just give a mild warning for a recently expired certificate 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.

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

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

#64

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.

A warning with a clear clickthrough button would work for alerting - the default TLS warnings are designed to be somewhat hard to bypass to make people think twice.

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

#65
post #28

Earlier quoted context omitted.

I think it’s mostly Apple and maybe Google who have the hard-ons for the shortest expiries possible.

To be fair, if someone managed to steal a set of keys to Gmail.com and icloud.com, I would want them to expire as short a time as possible too.

That is right, but one thing is not like the other. You have always been free to set expiry low on your own certificates, but that is not the same as enforcing it on everyones ceritificate.

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

#66
post #61

Earlier quoted context omitted.

I updated the title. Let me know if you think it's more accurate. It did appear as down for me though.

Yeah, thanks

I did not intend this to hit the top of the front page lol. I just posted it and then came back 15 minutes later to it having exploded.

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

#68

Earlier quoted context omitted.

To be fair, if someone managed to steal a set of keys to Gmail.com and icloud.com, I would want them to expire as short a time as possible too.

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

Revoking doesn’t really work.

https://garantir.io/certificate-revocation-challenges-and-be...

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

#69

Earlier quoted context omitted.

To be fair, if someone managed to steal a set of keys to Gmail.com and icloud.com, I would want them to expire as short a time as possible too.

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.

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

#70
post #32

Let's Encrypt has been working normally for most of the day. There was a ~90 minute period during which some of our users would have received a higher error rate due to upstream networking issues, but the majority of requests were successful even during that period. 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 respons…

I'm not sure if your higher error rate is sticky per user or something, but I've tried 10+ times throughout the day and have had 0 successes. They all come back as internal server error. That's why I eventually posted.

Why are you trying? Doesn’t Caddy (or something) just takes care of this well in advance and should have no issues with one or several days of my service at all at any time?

Edit: my bad. I’ve tried as well recently, when you’re rushing to get your new domain up of course…

Post reply on HN