Can someone else confirm - I do not have any Let's Encrypt-issued certificates, but I have been encountering problems with the chain-of-trust in certificates issued to vendors as early as 2026-05-28 22:50:39Z. I am still working with two vendors to determine if they have configured an invalid chain-of-trust, or they are receiving it from Let's Encrypt, but since both worked fine before 5/28 and now have the same error, I suspect it is from Let's Encrypt. (One received new certificates 5/28, the second 5/30).
It appears that Let's Encrypt is including an expired ISRG Root X2 certificate in the chain-of-trust, starting last week. This certificate was cross-signed by ISRG Root X1 and expired in September 2025.
# Subject = ISRG Root X2
# SubjectKey = 7c4296aede4b483bfa92f89e8ccf6d8ba9723795
# SerialNumber = 079e492886376fd40848c23fc631e463
# Lifetime = 2020-09-03 00:00:00Z - 2025-09-15 16:00:00Z
# Issuer = ISRG Root X1
# IssuerKey = 79b459e67bb6e5e40173800888c81a58f6e99b6e
SSLLabs reports the same expired X2 cert in the EC256 certificates issued to the websites:
Some clients are working as they are overriding with the new self-signed ISRG Root X2 CA in Windows trusted cert store, but I have other clients where the X2 certificate is not a trusted root store (Linux machines, Palo Alto firewalls, etc.).
Can Let's Encrypt repackage the chain-of-trust with the compatibility ISRG Root X2 certificate, cross-signed by X1 and expiring September 2032?
# Subject = ISRG Root X2
# SubjectKey = 7c4296aede4b483bfa92f89e8ccf6d8ba9723795
# SerialNumber = 6c8f1dc727c7117f7baf853ac980f9cd
# Lifetime = 2026-05-12 10:00:00Z - 2032-09-02 09:59:59Z
# Issuer = ISRG Root X1
# IssuerKey = 79b459e67bb6e5e40173800888c81a58f6e99b6e
Let's Encrypt are currently only serving unexpired and valid certificates. That certificate hasn't been used since 2024.
What's probably happening is that there's a cache in your system which doesn't get rid of old or expired certificates.
Edit: This is only a problem now as YE/YR are now used for all profiles, see Upcoming Let’s Encrypt Profile Changes On May 13, 20th, and 27th.
The issue isn't in the certificates that Let's Encrypt issued to the servers, since the chain provided in the ACME protocol includes the updated correctly signed unexpired certificates. It's likely to be something wrong with how those servers are configured, since they should be serving the chain which the ACME protocol gave them from Let's Encrypt, but perhaps are configured to serve some other broken chain instead.
It's not my system that has the expired certificate in cache and multiple new tests through SSLLabs on Friday and today show that SSLLabs is receiving the expired certificate in the additional certificates supplied by the server. I was also able to pull this same chain, sent from the server, on my home Linux PC. It could be that the vendor's servers have a static chain configured locally to send, but as both recently renewed and started doing this I suspect not.
Eltropy_chain2-0_full_cert_chain.txt (6.6 KB)
Right, but what my fellow volunteers are saying is that those servers are sending the invalid chain. You really need to work with them to get that chain corrected. Or, refer them here for assistance.
I think those servers are sending a "custom" chain they created themselves. Perhaps by removing one or more intermediate certs from the chain they were given and adding that expired one.
Until recently that may have worked as the other certs in the chain led to roots that are trusted by the client (that is, ISRG Root X1). So, this long-expired intermediate was ignored. But, recently Let's Encrypt started issuing from their new Y generation. This has a new chain for 3 different roots (YR/YE, X2, X1).
But, the "custom" chain these servers use dropped the proper intermediate for X1 replacing it with the long-expired one. This causes clients that don't have YR/YE or ISRG Root X2 in their trusted store to fail.
Note YR/YE are not yet in any public trust stores but people could potentially put them there. This is unlikely. Let's Encrypt is in the process of having them added. This new chain is the first step.
Yes, it looks like those two servers are sending expired cross-sign versions in their ECDSA chains. I don't think there's anything Let's Encrypt or this forum can do about it. If the operators of those servers want to post here explaining how they configure their servers to serve the chains from their ACME clients, we might be able to help them serve a valid chain. But I think they would have needed to go out of their way to be broken like that.
I currently have support tickets open with both vendors to look at their servers as well. One has passed to their engineering department to investigate, no response from the other yet. I suspect both are having their servers hosted by third parties, so another layer of diffusion in getting the details to correct person... it may take a while. Thanks.
As noted in the post below, Cloudflare has an incident involving a subset of Let's Encrypt certs. If your two services are using Cloudflare services it may be worth giving them the link to that incident report:
