Hi Team, I noticed that ISRG Root X2 certificate which is cross signed by 'ISRG Root X1' is about to expire by September 2025. Do you have a plan to renew it? if so, when can we find the renewed certificate listed in the Certificates web page please?. If not, is it fine to migrate to ISRG Root X2 (self-signed)? Should we be aware of any impact if we migrate, please?
Please assist. Thanks.
Let's Encrypts new ECDSA intermediates (Ex) have a direct signature to both ISRG Root X1 and ISRG Root X2. This removes any need for a cross sign from ISRG Root X2 to X1, as the intermediates have a direct link already. This was deployed in 2024: Deploying Let's Encrypt's New Issuance Chains
Since then, the cross-sign has not been included in any chains offered by Let's Encrypt. It should no longer be used by a server. Your server should always use the chains offered by Let's Encrypt. It is unlikely that Let's Encrypt will renew the cross-signed X2, as it is obsolete.
Not all operating systems trust ISRG Root X2. See the certificate compatibility page: Certificate Compatibility - Let's Encrypt. Depending on your use case, you may be able to accept this compatiblity. Note that by default, Let's Encrypt issues an ECDSA chain that terminates at ISRG Root X1 and does not use X2 at all. You can opt into the X2 chain if you can accept the reduced compatibility.
@balamurugan Are you manually configuring your chain to include this cross-sign? As Nummer described, starting a year ago the chains supplied do not use the cross-sign.
Last year some people asked about it and one LE staff member described an option to manually update a provided chain. LE also wanted more info about why someone would need this. See: Use both X1 and X2 chains for ECDSA certificates - #2 by mcpherrinm
I also doubt that a new cross-sign will be issued.
But, you should describe why you manually create your own chain and the need for the cross-sign.
Thank you so much for your response.
We are client and not the server. we really do not need the cross sign. I will make sure our trust store keeps the Roots and intermediates - not the cross signed any more. Thanks for the support.
As a trust store, you should include both ISRG Root X1 and ISRG Root X2 if you want to support all Let's Encrypt certificates. Trust stores should not include any intermediates - those are supplied by the server and are trusted via the root certificate. You also do not need to include any cross-signs: The standalone versions of the roots is what you're looking for. ISRG Root X1 is more widely used than X2, but trusting both would be optimal.
If you're supplying an embedded device that talks to Let's Encrypt, also consider adding an extra non-Let's Encrypt root for recovery purposes.
Got it Thank you again.
FYI, this was discussed here: Renewing X2-by-X1 cross-signed root
I have downloaded the standalone version of ISRG root X2 and tried to add to our security key database. But I face the following error.
Processing terminated. Problem found in certificate 1 in the chain.
From Google I can see the following explanation..
The error "Processing terminated. Problem found in certificate 1 in the chain" indicates an issue with the certificate chain used for secure communication, specifically the first certificate in the chain is not trusted. This typically means the client device or application cannot verify the server's certificate because it doesn't recognize the issuing certificate authority or the chain of trust is broken.
Can you help sort this issue ?
Thanks,
Bala.
what kind of tls library the client uses?
Yes, because my crystal ball has told me what kind of "security key database" you're actually talking about 
Sooo, no, not really.
Your error message says "the first certificate in the chain is not trusted" while you're (or should be) adding that trusted root. So it looks like you're not adding the root correctly or perhaps not in the correct place, I dunno.
Hi, Sorry, Its Mainframe. I thought that the cert downloaded was having issues .. Because I follow the same process for other certs, which work as expected, but problem faced only on this one particularly. Let me check once internally about this issue, if this has to anything to do with our security task.
Thanks for looking and for the suggestion
Dang, this is brilliant. This is the first time I've seen this idea mentioned, and it would have solved so many issues with people who deployed embedded devices.
Sooo, IBM z/OS I guess?