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.
> While it hasn't really taken off outside of Firefox
Thus doesn’t really work. Sadly.
naturalmovement•Jun 19, 2026
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.
flakes•Jun 19, 2026
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.
naturalmovement•Jun 19, 2026
> 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.
dijit•Jun 19, 2026
> 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..
icedchai•Jun 19, 2026
So true. The last time I worked with a person with an actual "system administrator" title was 2009!
spragl•Jun 19, 2026
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.
Dylan16807•Jun 19, 2026
If it goes past 24 hours, that becomes a real worry.
If anyone is renewing certificates with less than a day remaining, that's an issue on their end far more than anything else.
Kesseki•Jun 19, 2026
To be clear, “Degraded Performance” means just that, not “down.” Let’s Encrypt’s issuance is mostly working fine.
widdakay•Jun 19, 2026
I have tried many times to renew my certs and have had 0 successes throughout today. It seems to be 100% degraded to me.
Kesseki•Jun 19, 2026
That’s unexpected. Please post details on the “Help” topic of the Let’s Encrypt community forum so that folks can take a look.
saagarjha•Jun 19, 2026
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”.
Kesseki•Jun 19, 2026
Although I only post here personally, I work for Let’s Encrypt.
dlcarrier•Jun 19, 2026
Let them know that they're having an outage. If their monitors aren't telling them so, they might need to host them off-site.
Kesseki•Jun 19, 2026
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.
number6•Jun 19, 2026
Thanks you for your work!
ofrzeta•Jun 19, 2026
It would be better to say this upfront. I am not blaming you in any way but this would prevent responses such as the parent's (hopefully).
AceJohnny2•Jun 19, 2026
I thought it meant "electricity has ceased to be a physical phenomenon in the general vicinity of our servers"
AceJohnny2•Jun 19, 2026
A common confusion; this interpretation only applies to OVH.
That would a Microsoft'ese, "Some regions are encountering issues" => "The entire world is down, but our status page is working"
zelphirkalt•Jun 19, 2026
I also see that fitting into the corporate language of Gaslightese.
gib444•Jun 19, 2026
What % of requests succeeded vs failed? How many certificates were issued during the outage vs the average? That might actually clear things up
greatgib•Jun 19, 2026
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.
pibaker•Jun 19, 2026
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.
evbogue•Jun 19, 2026
Like peers could sign sites?
treesknees•Jun 19, 2026
ZeroSSL – free 90-day certs via ACME, also has a web UI for cert management
Google Trust Services – free ACME certs, requires a Google account for registration
SSL.com Free DV SSL – offers free 90-day certs through ACME
polpo•Jun 19, 2026
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.
icedchai•Jun 19, 2026
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.
otabdeveloper4•Jun 21, 2026
This is Stockholm syndrome. You were taken hostage and beaten and raped. Now the rape has stopped and you get gruel on schedule, and you're enamored with your captor.
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.
JumpCrisscross•Jun 19, 2026
Have the EU or Canada pushed to launch an analog of their own?
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.
nubinetwork•Jun 19, 2026
It's a good thing that acme clients try to renew early, rather than leaving it to the last minute...
ardeaver•Jun 19, 2026
I realize this is very much not the point, but the fact that the "Active Incident" banner is green is upsetting.
NewJazz•Jun 19, 2026
We're operating normally, but with reduced redundancy. We continue to work with our upstream ISP to identify and resolve the issue.
Kesseki•Jun 19, 2026
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.
dxdm•Jun 19, 2026
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.
Kesseki•Jun 19, 2026
We do say it. That's what the "Incident Status" field is there for.
dxdm•Jun 19, 2026
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.
dlcarrier•Jun 19, 2026
Their monitors don't seem to be detecting the outage. Sometimes they run directly on the server, and aren't able to detect routing or DNS problems.
dlcarrier•Jun 19, 2026
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
jaas•Jun 19, 2026
> 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.
LtWorf•Jun 19, 2026
> weeks ago
How long do you think a certificate lives?
jaas•Jun 19, 2026
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.
nottorp•Jun 19, 2026
How's the push for 48 hour certificates going?
selcuka•Jun 19, 2026
> If you're one of the few early adopters of short-lived (6-day) certs you should renew at 3 days
Apparently certificates are becoming OCSP-only with a TTL.
bebop•Jun 19, 2026
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.
Biganon•Jun 19, 2026
They work at letsencrypt, I'm pretty sure they know.
mannyv•Jun 19, 2026
"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?"
ozim•Jun 19, 2026
If they make 7 days grace period then expiration date will be a lie and of course every one will use grace period like it would be normal thing ;)
NewJazz•Jun 19, 2026
Roulette grace period, keep them on their toes.
selcuka•Jun 19, 2026
> 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.
dingaling•Jun 19, 2026
> 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.
MobiusHorizons•Jun 19, 2026
How does that help? Seems like mostly the end user suffers.
mannyv•Jun 19, 2026
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?
mcpherrinm•Jun 19, 2026
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.
tgsovlerkhgsel•Jun 19, 2026
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.
tgsovlerkhgsel•Jun 19, 2026
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.
lambdaone•Jun 19, 2026
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.
hannob•Jun 19, 2026
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.
bluesign•Jun 19, 2026
What you want is warning when certificate expiry in next 7 days, then everyone would update before the warning.
jaas•Jun 19, 2026
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.
widdakay•Jun 19, 2026
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.
jaas•Jun 19, 2026
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/
widdakay•Jun 19, 2026
I ran the exact same command now and it's working, so it is possible I was unlucky and was hitting all the worst possible cases.
sgt•Jun 19, 2026
Could it be that he was simply throttled while retrying? That seems plausible, and it would make it seem like a long outage.
widdakay•Jun 19, 2026
I updated the post title to say (Fixed) now.
jaas•Jun 19, 2026
Since Let's Encrypt wasn't down most of the day if would be helpful if you could update the title to reflect that.
widdakay•Jun 19, 2026
I updated the title. Let me know if you think it's more accurate. It did appear as down for me though.
jaas•Jun 19, 2026
Yeah, thanks
widdakay•Jun 19, 2026
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.
jaas•Jun 19, 2026
No worries
taspeotis•Jun 19, 2026
Thanks for securing the web
sam_lowry_•Jun 19, 2026
Thank them for making the web depend on a single US-based shady org, as if DNS was not enough.
cpach•Jun 19, 2026
Feel free to launch your own CA.
sam_lowry_•Jun 19, 2026
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.
soco•Jun 19, 2026
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.
sam_lowry_•Jun 19, 2026
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.
soco•Jun 19, 2026
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...
sam_lowry_•Jun 19, 2026
Regulation is enforced in courts only in the US, heh.
Natfan•Jun 19, 2026
am i a carrier when i host my own wifi network?
teekert•Jun 19, 2026
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…
po1nt•Jun 19, 2026
Let's encrypt is a single point of failure for a large percentage of the internet.
gsliepen•Jun 19, 2026
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.
doublerabbit•Jun 19, 2026
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.
po1nt•Jun 19, 2026
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.
po1nt•Jun 19, 2026
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.
gsliepen•Jun 20, 2026
Ok, but that would just be your own website having a single point of failure, not that Let's Encrypt is a single point of failure. Otherwise you could call every certificate authority a single point of failure.
anal_reactor•Jun 19, 2026
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.
po1nt•Jun 19, 2026
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.
anal_reactor•Jun 20, 2026
> electricity outages at your home
I haven't had one in 20 years, which kinda proves my point.
10 Comments
https://garantir.io/certificate-revocation-challenges-and-be...
https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...
Thus doesn’t really work. Sadly.
The last browser where revocation worked properly is Internet Fucking Explorer.
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.
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.
Sorry, we don't hire those anymore.
Best I can do is a YAML monkey who knows how to glue cloud services together..
If anyone is renewing certificates with less than a day remaining, that's an issue on their end far more than anything else.
ref: https://www.reuters.com/article/world/millions-of-websites-o...
> Some clients may encounter 400 and 500 error responses.
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
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.
Let's Encrypt is incredible.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
P.S. JS injection into TCP packets and other meddling with passthrough data should be banned legally, not technically via encryption.
Edit: my bad. I’ve tried as well recently, when you’re rushing to get your new domain up of course…
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.
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.
I haven't had one in 20 years, which kinda proves my point.