Hey, So we got to know that the root certificate "IdentTrust DST Root CA X3" is expiring on Sep'30. We are using multiple Letsencrypt certificates, which show 2 chains having Issuer names as "ISRG Root X1" and "DST Root CA X3". We would like to know if we need to take any action from our end for this if this service goes down it will cause business impacting downtime for our customers.
For your reference, I have attached the screenshot for the certificate chain:
Please read this:
For the big majority of the clients the connection to your web server is going to work after that date.
@bruncsak Could you please explain a little more on which browser versions might possibly get affected. I can see that you have cross-signed the old one for old browsers. But we just wanna make sure.
With the current chain you are providing, systems that are using openSSL older than version 1.1.0.
Hi @bruncsak
When can we expect to see certs issued with the new roots? I issued a new cert today and it was still signed with the R3 and DST Root signers that are set to expire next week.
Welcome to the Let's Encrypt Community, Cody 
There is no upcoming chain change. This chain will continue to be served:
The corresponding root certificate is:
Notice that ISRG Root X1 signed by DST Root CA X3 outlives DST Root CA X3 signed by itself by 3 years. The expiration of DST Root CA X3 signed by itself is meant to be irrelevant since it should still be trusted after expiration by virtue of being included in trust stores in the case of extending Android compatibility.
This sounds a bit misleading. Trust stores (well, except Android) usually do not trust expired certificates (there are a couple of exceptions though, especially when it comes to timestamped signatures). Trust is usually not derived from an expired certificate.
Trust is instead established via ISRG Root X1 (a different root), which will not be expired. The expiration date of ISRG Root X1 signed by DST Root CA X3 is also only relevant for Android devices.
The majority of clients will anchor their trust with ISRG Root X1, completly disregarding DST Root CA X3. Chains using DST Root CA X3 as the trust anchor will in general (with exceptions) become invalid.
I was fairly certain that having a trust anchor in a trust store makes it trusted regardless of expiration depending upon implementation. 
Wasn't the entire purpose of cross-signing ISRG Root X1 beyond the life of DST Root CA X3 to take advantage of DST Root CA X3 being in trust stores and thus having its expiration ignored?
The purpose was to extend Android compatibility, because Android doesn't enforce expiry dates on trust anchors. This is a special property of Android and not something you can expect from other operating systems.
Ah... I overgeneralized it. That makes sense. The reasoning for the action I cited is still correct, just not for the general scope.
Personally, I view the expiration of certificates much like the expiration of operators' licenses. I don't suddenly lose my ability to drive just because my license is expired. Similarly, the encryption key associated with a certificate doesn't cease to exist or function when the certificate expires. Sure, I'm no longer "approved" as a driver and the domain names and public key in a certificate are no longer "approved" as associated. I suppose I see the expiration date as a kind of autorevocation. A rather inconvenient one at times.
The certificates issued these days has valid (alternate) trust chain to the non-expiring "ISRG Root X1" root certificate.
And has been doing so for many weeks now.
Hello Team,
We are also using multiple lets encrypt ssl certificate in our server, as per [IdenTrust DST Root CA X3 expiry, can anything need to do from our side to avoid any issue after 30th Sep 2021.
HI @sevakant, welcome to the LE community forum 
Have a look at the video posted here:
Thanks for the response everyone, I apologize, SSL has never been a strong point of mine, I didn't realize a cert could be signed by two different trust chains at the same time. Everything seems to be working find using the ISRG chain instead of the DST chain. Thanks again.
(and sorry it took me a while to reply, gmail was sending the notifications to my junk folder)
It's not signed by anything differently: it's just signed by a single private key which is packaged into different certificates.
Just imagine sending the exact same CSR file to all the CAs (free and paid).
You would have a cert that is signed by all of them (individually).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
