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.
6 Likes
We had this discussion for CentOS + OpenSSL here:
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)
6 Likes
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. 
5 Likes
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
4 Likes
R3 signed by DST Root CA X3 (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 (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
4 Likes
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)
- ISRG Root X1 (sig DST Root CA X3)
Expected to be in trust store:
Alternate Chain
Being served:
- End-entity/leaf certificate (sig R3)
- R3 (sig ISRG Root X1)
Expected to be in trust store:
5 Likes
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?
2 Likes
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 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.
5 Likes
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
1 Like
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, certificate example for "ISRG Root X2" is available but...
Regarding "ISRG Root X1" certificate example, the full chain still use "DST Root CA X3" (like my current certificates)
contrary to "ISRG Root X2" certificate example
1 Like
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/ to see the chain send by the webserver.
3 Likes
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
- Requesting certificate...*
I retrieved the full string from 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....
3 Likes
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:
- Your leaf must use an ECDSA keypair (ISRG Root X2 and E1 are both ECDSA themselves).
- 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
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 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 too.
8 Likes
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
5 Likes
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 ?
2 Likes
If we apply certificate through ACME protocol from Let's Encrypt after 30/9/2021 , which root CA would signed this certificate?
2 Likes
Unless you have special needs (needing to support older OpenSSL/LibreSSL/GnuTLS/embeddedTLS versions), nothing. (OpenSSL Client Compatibility Changes for Let’s Encrypt Certificates)
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
This chain will continue to be used, even after DST Root CA X3 has expired. This ensures Android compatibility, 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.
7 Likes
When comes the time that the AIA-URL "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.
7 Likes
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). 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.
5 Likes
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!
5 Likes