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 response to a previous submission title implying that Let's Encrypt was entirely down most of the day.
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.
It would not have been sticky for the entire day. If it was sticky at all, it would have been only during the 90 minute period I referenced. It's most likely that there is some other issue with how you're requesting the cert. Folks can help debug at: https://community.letsencrypt.org/
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…
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. 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
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.
> That explains why one of my IoT vendors is using an expired certificate.
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.
"nobody should be renewing their certificate within 90 minutes of expiration"
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?"
> If I'm required to renew it 30 days before the expiration date then the expiration date is a lie, isn't it?
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.
Mostly 90 days, and we recommend renewing at 60 days for 90 day certs. That gives more than four weeks of leeway.
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.
90 days moving to 45 but you can and should renew earlier than that. Automating this process means that you should be request a new certificates roughly 60 days (or 30 soon) after the issuance of the previous certificate. That way you would have plenty of time to deal with renewal issues. The process for renewal should have back off and retries built in. This prevents a situation where a down time for the issuer means that your production environments are non-functional.
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.
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.
Let's Encrypt is operating normally. If you're having trouble, please post the details on the community forum so that folks can help you out. There is external monitoring in place.
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.
I use acme.sh for certs on my personal server and was a little surprised when it started using ZeroSSL by default. Despite being more "corporate" I decided to roll with it and it's worked just fine.
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.
The banner's colour is based on the "Incident Status;" it's green because services are currently operational. It would be yellow or red if the impact were more severe.
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.
You are getting down-voted for this, which I think is a bit unfair. (I expect I'll get the same.)
Although you don't expand your thesis, as a general feeling, I agree. But, to be fair, it has always been thus, and it has been this way in every forum ever.
I'm old enough to remember the irony in "I read about it on the internet so it must be true" statements, which have existed since the internet was News (NNTP) not web.
In truth, any time you get a random group of people together, of different ages and backgrounds, all of whom self-describe as "smart" you're going to get a lot of chaff mixed in with the wheat.
To some extent you need to simply ignore the nonsense. There's plenty of it and "correcting people who are wrong" is seldom received well.
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
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.
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?"
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.
How long do you think a certificate lives?
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.
Apparently certificates are becoming OCSP-only with a TTL.
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?
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.
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.
ref: https://www.reuters.com/article/world/millions-of-websites-o...
If anyone is renewing certificates with less than a day remaining, that's an issue on their end far more than anything else.
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.
https://garantir.io/certificate-revocation-challenges-and-be...
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.
Although you don't expand your thesis, as a general feeling, I agree. But, to be fair, it has always been thus, and it has been this way in every forum ever.
I'm old enough to remember the irony in "I read about it on the internet so it must be true" statements, which have existed since the internet was News (NNTP) not web.
In truth, any time you get a random group of people together, of different ages and backgrounds, all of whom self-describe as "smart" you're going to get a lot of chaff mixed in with the wheat.
To some extent you need to simply ignore the nonsense. There's plenty of it and "correcting people who are wrong" is seldom received well.