# Help thread for DST Root CA X3 expiration (September 2021) **URL:** \ **Category:** Help\ **Created:** [April 6, 2021, 11:43pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190 "2021-04-06T23:43:50Z")\ **Posts on this page:** 20\ **Page:** 7
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [July 5, 2021, 8:40pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/759 "2021-07-05T20:40:36Z")
> [@griffin](#): > > Maybe it depends upon the sophistication of the client building the chain of trust. Throw out the served ISRG Root X1 signed by an expired certificate (DST Root CA X3) and use the unexpired, self-signed ISRG Root X1 in the trust store. Yes, quite a few clients can't do that. If you tell them: Here's ISRG Root X1 signed by DST Root CA X3 they can't understand that ISRG Root X1 is a root they know - they will always follow the chain up to DST Root CA X3, no matter what you put into their trust store. This is bad behaviour, but sadly reality. ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [July 5, 2021, 8:43pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/760 "2021-07-05T20:43:19Z")
We had this discussion for CentOS + OpenSSL here: > [@RHEL/CentOS 7 OpenSSL client compatibility after new chain](https://community.letsencrypt.org/t/rhel-centos-7-openssl-client-compatibility-after-new-chain/151969/11): > > … The results were: Sometimes. It seems to fix OpenSSL 1.0.2, but not OpenSSL 1.0.1. (I believe this is somehow related to OpenSSL's `PARTIAL_CHAIN` feature) ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [July 5, 2021, 8:45pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/761 "2021-07-05T20:45:45Z")
That seems to cover all the bases. For being such a sticky problem, it really isn't all that complex, which unfortunately offers limited degrees of freedom to find alternative solutions. πŸ˜• ---
**Author:** ![Orthank](https://avatars.discourse-cdn.com/v4/letter/o/c2a13f/32.png) [@Orthank](https://community.letsencrypt.org/u/Orthank)\ **Post date:** [July 5, 2021, 8:49pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/762 "2021-07-05T20:49:49Z")
It seems like the right solution but unfortunately it doesn't work. Despite the addition of the parameter (--preferred-chain "ISRG Root X1"), the certificate that I renewed continues to have "DST Root CA X3" as root certificate However, the intermediate certif, is R3 which expires on September 29 ![](https://global.discourse-cdn.com/letsencrypt/original/3X/0/5/05f99915557327388242ea97ce7e98f3d3a5dfbf.png) ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [July 5, 2021, 8:54pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/763 "2021-07-05T20:54:50Z")
> [@Orthank](#): > > However, the intermediate certif, is R3 which expires on September 29 [R3 signed by DST Root CA X3](https://crt.sh/?id=3479778542) (not presently being served) expires on September 29, 2021: > Validity > Not Before: Oct 7 19:21:40 2020 GMT > Not After : Sep 29 19:21:40 2021 GMT [R3 signed by ISRG Root X1](https://crt.sh/?id=3334561879) (presently being served for both the default and alternate chains) expires on September 15, 2025: > Validity > Not Before: Sep 4 00:00:00 2020 GMT > Not After : Sep 15 16:00:00 2025 GMT ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [July 5, 2021, 9:10pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/764 "2021-07-05T21:10:04Z")
For full clarity, these are the chains being served at present: ## Default Chain Being served: - End-entity/leaf certificate (sig R3) - [R3 (sig ISRG Root X1)](https://crt.sh/?id=3334561879) - [ISRG Root X1 (sig DST Root CA X3)](https://crt.sh/?id=3958242236) Expected to be in trust store: - [DST Root CA X3 (sig DST Root CA X3)](https://crt.sh/?id=8395) ## Alternate Chain Being served: - End-entity/leaf certificate (sig R3) - [R3 (sig ISRG Root X1)](https://crt.sh/?id=3334561879) Expected to be in trust store: - [ISRG Root X1 (sig ISRG Root X1)](https://crt.sh/?id=9314791) ---
**Author:** ![Orthank](https://avatars.discourse-cdn.com/v4/letter/o/c2a13f/32.png) [@Orthank](https://community.letsencrypt.org/u/Orthank)\ **Post date:** [July 5, 2021, 9:30pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/765 "2021-07-05T21:30:22Z")
Thank you for that clarification. Now I have to figure out why, even if I force the preferred chain (parameter --preferred-chain "ISRG Root X1" with dehydrated), it still uses DST Root CA X3 Could it be because I have 4 certificates on the same server and root/intermediate are somehow shared? ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [July 5, 2021, 9:45pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/766 "2021-07-05T21:45:20Z")
This isn't really a function of which or how many certificates you have, but a function of how those certificates are served. If your webserver is pinning the [R3 signed by DST Root CA X3](https://crt.sh/?id=3479778542) intermediate and therefore only serving the leaf certificate and that pinned intermediate, that's a problem. If, on the other hand, your webserver is serving the intermediate(s) after each leaf certificate as given by your ACME client, that's correct and probably the best you can do. ---
**Author:** ![HardcoreGames](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/hardcoregames/32/25223_2.png) [@HardcoreGames](https://community.letsencrypt.org/u/HardcoreGames)\ **Post date:** [July 6, 2021, 10:55pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/767 "2021-07-06T22:55:53Z")
Given a web server today, it possibly can host over 1000 wordpress sites without much problem so given every site wants a certificate it does suggest some steps will be needed with a busy host biggest server I have a photo of has 8 processors and 8TB of RAM, overkill as swarms of blades can handle a larger number of tasks ---
**Author:** ![Orthank](https://avatars.discourse-cdn.com/v4/letter/o/c2a13f/32.png) [@Orthank](https://community.letsencrypt.org/u/Orthank)\ **Post date:** [July 24, 2021, 10:04am UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/768 "2021-07-24T10:04:45Z")
Hello, I'm still working on the issue with my webserver in order to be ready for DST Root CA X3 expiration. Is it already possible to request a certificate signed by ISGR Root X2? When I try to use ISRG Root X2 as preferred-chain wit dehydrated, I have the following error _ERROR: Alternative chain with CN = issuer-cn=ISRG Root X1 not found, available options: DST Root CA X3, ISRG Root X1_ I guess it is possible as on [Chain of Trust - Let's Encrypt](https://letsencrypt.org/certificates/), certificate example for "ISRG Root X **2**" is available but... Regarding "ISRG Root X **1**" certificate example, the full chain still use "DST Root CA X3" (like my current certificates) ![image](https://global.discourse-cdn.com/letsencrypt/original/3X/e/9/e9abf1f62007f1b269289d8f55303ee3bfd2913a.png) contrary to "ISRG Root X **2**" certificate example ![image](https://global.discourse-cdn.com/letsencrypt/original/3X/8/3/83010cfdb9f92125b6d972f07e85f1437601a127.png) ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [July 24, 2021, 10:16am UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/769 "2021-07-24T10:16:53Z")
> [@Orthank](#): > > When I try to use ISRG Root X2 as preferred-chain wit dehydrated, I have the following error > _ERROR: Alternative chain with CN = issuer-cn=ISRG Root X1 not found, available options: DST Root CA X3, ISRG Root X1_ Is there a typo in that error message? As you say you're requesting _X2_, but the error says you requested _X1_ which later on it says it should be available πŸ€” Also, the X2 root is _just_ for ECDSA certificates and _not_ for RSA certificates. So if you're requesting certs with RSA keys, you can't use X2, but just X1.. But X1 is fine too of course πŸ™‚ Also, never use browsers to detect the certificate chain: browsers can build any chain they want, as long as it's valid. Browsers don't necessarily use the intermediate certificates send by the webserver. Use tools like [https://whatsmychaincert.com/](https://whatsmychaincert.com/) to see the chain send by the webserver. ---
**Author:** ![Orthank](https://avatars.discourse-cdn.com/v4/letter/o/c2a13f/32.png) [@Orthank](https://community.letsencrypt.org/u/Orthank)\ **Post date:** [July 24, 2021, 12:25pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/770 "2021-07-24T12:25:29Z")
Woops, you're right, there is a typo in the error message, I copied/pasted the wrong one. Here's the correct one : _ERROR: Alternative chain with CN = ISRG Root X2 not found, available options: DST Root CA X3, ISRG Root X1_ Thank you for the information regarding ECDSA/RSA certificates. I completely missed this point... so another option to add to the command line --algo (-a) rsa|prime256v1|secp384r1 However it does not solve the problem _dehydrated -c -x -d --preferred-chain "ISRG Root X2" --algo secp384r1_ _[...]_ - - Requesting certificate...\* _ERROR: Alternative chain with CN = ISRG Root X2 not found, available options: DST Root CA X3, ISRG Root X1_ I retrieved the full string from [valid-isrgrootx1.letsencrypt.org](http://valid-isrgrootx1.letsencrypt.org) via the site you provided but I get the same result with "DST Root CA X3" instead of "ISRG Root X1" I think I'm missing something here.... ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [July 24, 2021, 1:24pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/771 "2021-07-24T13:24:35Z")
ISRG Root X1 and ISRG Root X2 are roots. Roots never sign subscriber certificates ("leafs") directly. Instead, they sign intermediate certificates which in turn sign leafs. The intermediate certificate currently in use (by default) is R3, which is signed by ISRG Root X1. ISRG Root X1 in it's current form is additionally signed by DST Root CA X3. There's an alternate chain available which does not include this last signature and therefore terminates at ISRG Root X1. ISRG Root X2 is a brand new root certificate. It has signed an intermediate certificate called "E1". It is possible to get a leaf certificate signed by E1, but only under two conditions: 1. Your leaf must use an ECDSA keypair (ISRG Root X2 and E1 are both ECDSA themselves). 2. As this feature is currently in a "sort-of" beta, only allow-listed accounts can get signed by E1. To hop onto the allowlist, you need to fill out a form: [ECDSA availability in production environment](https://community.letsencrypt.org/t/ecdsa-availability-in-production-environment/150679) With both conditions fulfilled, you get a leaf certificate signed by E1, which is signed by ISRG Root X2, which is signed by ISRG Root X1. ISRG Root X2 is not in any root program as of today, therefore it is impossible to request a chain from LE terminating at X2 - it would just result in errors. It will take a bunch of years until X2 is widely supported (X1 is in root programs for almost 5 years, and people are still concerned). [valid-isrgrootx1.letsencrypt.org](http://valid-isrgrootx1.letsencrypt.org) is an example for a site that terminates at ISRG Root X1 and does not include the final signature up to DST Root CA X3. However, some TLS implementations (e.g browsers) tend to build their own chains, which can differ from the chain send by the server - this causes seemingly "incorrect" results in their displays. PS: You might want to read [Production Chain Changes](https://community.letsencrypt.org/t/production-chain-changes/150739) too. ---
**Author:** ![Orthank](https://avatars.discourse-cdn.com/v4/letter/o/c2a13f/32.png) [@Orthank](https://community.letsencrypt.org/u/Orthank)\ **Post date:** [July 24, 2021, 2:11pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/772 "2021-07-24T14:11:01Z")
Thank you for your help. So... if I understand well, I do not need to worry about anything as E1, E2, R3, and R4 intermediate certificates will be renewed and resigned by ISRG Root X1 or ISRG Root X2 (depending on the key type) instead of DST Root CA X3 ---
**Author:** ![test\_mail\_new](https://avatars.discourse-cdn.com/v4/letter/t/97f17d/32.png) [@test\_mail\_new](https://community.letsencrypt.org/u/test_mail_new)\ **Post date:** [July 27, 2021, 5:32am UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/773 "2021-07-27T05:32:40Z")
If I have a certificate signed by this expiring DST Root CA X3 root certificate, what should I do between 30/9/2021 and my certificate's expiration date, for example 21/10/2021 ? Re-apply a new certificate, or this certificate is available between 30/9/2021 and 21/10/2021 ? ---
**Author:** ![test\_mail\_new](https://avatars.discourse-cdn.com/v4/letter/t/97f17d/32.png) [@test\_mail\_new](https://community.letsencrypt.org/u/test_mail_new)\ **Post date:** [July 27, 2021, 5:34am UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/774 "2021-07-27T05:34:45Z")
If we apply certificate through ACME protocol from Let's Encrypt after 30/9/2021 , which root CA would signed this certificate? ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [July 27, 2021, 11:39am UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/775 "2021-07-27T11:39:53Z")
> [@test\_mail\_new](#): > > If I have a certificate signed by this expiring DST Root CA X3 root certificate, what should I do between 30/9/2021 and my certificate's expiration date, for example 21/10/2021 ? Unless you have special needs (needing to support older OpenSSL/LibreSSL/GnuTLS/embeddedTLS versions), nothing. ([OpenSSL Client Compatibility Changes for Let’s Encrypt Certificates](https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816)) > [@test\_mail\_new](#): > > If we apply certificate through ACME protocol from Let's Encrypt after 30/9/2021 , which root CA would signed this certificate? Root CA's do not sign subscriber certificates ("leafs"). Roots sign intermediate certificates which in turn sign leafs. The certificate chain currently in use is: End-entity certificate ("leaf") ← R3 ← ISRG Root X1 ← DST Root CA X3 ([Production Chain Changes](https://community.letsencrypt.org/t/production-chain-changes/150739)) This chain will continue to be used, even after DST Root CA X3 has expired. [This ensures Android compatibility](https://letsencrypt.org/2020/12/21/extending-android-compatibility.html), but will break some clients named above. You can request an alternate chain\*, terminating at ISRG Root X1 (instead of DST Root CA X3), but this will cause problems with Android versions \< 7.1 (and will fix other clients). \*How to do this depends on your ACME client. Some modern clients have an option, usually called preferred-chain. ---
**Author:** ![maxi322](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@maxi322](https://community.letsencrypt.org/u/maxi322)\ **Post date:** [July 28, 2021, 1:40pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/776 "2021-07-28T13:40:39Z")
When comes the time that the AIA-URL "[http://r3.i.lencr.org/](http://r3.i.lencr.org/)" will serve the R3 Version that is signed by ISRG Root X1 and not the old R3 that is signed by DST Root CA X3 and is only valid until 29.09.2021? This can become a problem with improperly configured servers where the client browser tries to load the intermediate from the AIA Server after September 2021. ---
**Author:** ![peterg-l](https://avatars.discourse-cdn.com/v4/letter/p/59ef9b/32.png) [@peterg-l](https://community.letsencrypt.org/u/peterg-l)\ **Post date:** [July 29, 2021, 1:17pm UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/777 "2021-07-29T13:17:09Z")
I doubt, that a specific app will still work on older android devices after the expiration date of DST Root CA X3. We tried this: Renew of the Let'sEncrypt-SSL-Certificate for the backend-server of the app ([bayern-app-test.bayern.de](http://bayern-app-test.bayern.de)). It is now valid until 05 Oct 2021. Now I set the date on a Lollipop-Tablet manually to 02 Oct 2021. The app then gives an error message and in the log I find _error: HandshakeException: Handshake error in client (OS Error: CERTIFICATE\_VERIFY\_FAILED: certificate has expired(handshake.cc:359))_ Setting the date to 29 Sep 2021 makes the app work normal again. It doesn't match with what you were saying, that android doesn't check actively for expiration, or I misunderstood some part. ---
**Author:** ![nunoperalta](https://avatars.discourse-cdn.com/v4/letter/n/7cd45c/32.png) [@nunoperalta](https://community.letsencrypt.org/u/nunoperalta)\ **Post date:** [July 31, 2021, 1:59am UTC](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/778 "2021-07-31T01:59:00Z")
Hi everyone! This thread has become really long! πŸ™‚ Just want to confirm that the same applies, that old Androids will continue to be OK until Sep 2024, but iOS \< 10 will get certificate errors. Is that correct? I want to check with you before I go ahead and put a warning on my website advising iPhone users to upgrade their devices. What about MacOS \< 10.12.1 - will those will be affected too? Thank you! [Previous page](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190.md?page=6) [Next page](https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190.md?page=8)