In my website I'm using letsenctpt certificate. In some machines my website will not work because of the DST Root x3 certificate. So I need to download the certificate using this link "https://letsencrypt.org/certs/isrgrootx1.der" and install manually. I'm a service provider. So lots of people from world wide using our website. So I cannot manually doing this operation. I've installed the certificate again but it didn't work. When i try to download the file the letsenctypt is also not working on that machines so i need to forcefully doing that operation.
Please anyone suggest a solution for this?
Hi @santsinfo and welcome to the LE community forum 
Depending on the ACME client (and version) used, you may be able to issue a cert with the shorter/alternate chain [which relies solely on that ISRG Root X1 cert] OR switch to another trust chain [from another CA].
So, which ACME client (and version) are you using?
1 Like
Thanks for the reply. We are using certbot ACME client for the certificate. You mentioned about switching to another trust chain how can i switch to another trust chain.
1 Like
Please show the output of:
certbot --version
Not to hijack the thread, but looking forward to hear more about this. I'm on the same boat with a system disliking the now expired DST X3 certificate and disliking my incomplete chain if I leave DST X3 out. Unfortunately I cannot manipulate this system certificate trust store. certbot 1.21.0 user here, but I'll happily go by with any directions as given to the OP.
The Certificate you get from LetsEncrypt is known as the "End Entity" or "Leaf Certificate" or "Subscriber Certificate". They do not change when switching chains, so you can just test the alternate chains by downloading their files from Chain of Trust - Let's Encrypt
Your chain can either be*:
- LetsEncrypt R3 > ISRG Root X1 (cross signed) > DST Root CA X3 [Expired]
- LetsEncrypt R3 > ISRG Root X1 (self signed)
Certbot uses PEM files, and most servers use them as well. Some platforms will require DER or other formats.
There are docs about the current compatibility of the roots here: Certificate Compatibility - Let's Encrypt
If you are targeting clients in the known incompatible list, you will need to find another CA, but one may not exist.
If you are targeting clients in the "trust DST Root CA X3 but not ISRG Root X1" list, you can either instruct clients to manually update their trust stores with the ISRG Root X1 certificate, or find another vendor - but one may not exist.
The unfortunate truth is that you will not be able to have a chain compatible with all clients. This is not just true for LetsEncrypt, but for all free and commercial Certificate Authorities -- many trusted Root Certificates have expired or are expiring, and older machines/operating systems are simply not compatible because their vendors have stopped issuing security or trust-store updates. The DST Root CA X3 Certificate is the first MAJOR root certificate to have expired, but several lesser ones have recently expired and many of the other major trust roots are set to expire in the next 1-2 years.
If clients do not like the Expired DST, then they are most likely machines that are either out of vendor support or nearing it -- most vendors have implemented short-circuit logic in the past few years, and will not care about the DST root because they detect a trusted ISRG X1 certificate and ignore the presented chain. The cross-signed versions of ISRG X1 and LetsEncrypt R3 have the same Private/Public key pairings are the versions signed by LetsEncrypt, the only effective difference is the certificate which signed them.
If your server is having problems with the chains, then you should ensure you are running the latest OS patches, have the latest trust store installed, and have the most recent version of OpenSSL installed (if on Linux/BSD). In the past year or so, OpenSSL released a version that enables short-circuit logic by default, and most operating system vendors backported it to platforms in their service window.
* If you enroll in the ECDSA beta, there is another chain, but that is a very advanced topic.
3 Likes
Note to self: remember to use self signed Root CA LE certificates, not cross signed Root CA LE certificates. Thanks @jvanasco.
I'm using certbot 1.21.0
certbot v1.21.0 supports both LE trust paths.
You are already using the default/longer trust path, but there is another "shorter/alternate" trust path.
You can "enable" it in two ways:
- manually
Edit thefulchain.pem(orchain.pem) file used and remove the last cert. - using
certbot
reissue the cert using--preferred-chain "ISRG Root X1"
OR
(If that doesn't fix things) You can also try using another ACME friendly CA.
3 Likes
I tryied with the code but it didn't work. It shows that "--preferred-chain command not found" error. So I tried with
certbot renew --preferred-chain "DST Root CA X3" --force-renewal. But After this code executed my wibsite stopped working. So I again reinstall the certificate.
Very very very few clients care about the difference between the two. The only contexts I know of Cross-Signed certs potentially failing on, is if you're using OpenSSL's verify or building a sandboxed verification test with a lowlevel library. In those situations, you might trigger an error if presenting the cross-signed certificate as a root certificate (since it's not self-signed). Most end-user clients and usage contexts (e.g. probably every browser and networking library) will not care about that, and just care about the Certificate's key-pairing being in the trust store.
2 Likes
Hey @jvanasco, indeed clients that respect their trust store do not “care” about this, as once a certificate is added as trusted, the validation stops there.
For my particular case, the server application do check the entire chain during the certificate and key import process, as it does not have a trust store. As such, using the X1 cross-signed by the now expired X3 was causing me trouble. Same as leaving X3 out of the picture without using the self-signed X1 cert - the chain was incomplete. Which was one of the scenarios you pointed out.
Thanks again for refreshing things for me.
2 Likes
What I did for my application was to manually create a full chain of certificates, starting with the LE issued certificate, added the intermediate (R3) and the self signed Root CA from X1. That took away any references to the expired X3 and I was back on track. No need to any particular flags on the certbot, but again I already have a ton of other automations and manual hooks so not a biggie for me to create a new function.
Ah, yes. That is an edge case.
Adding to some potential confusion... The cross-sign for LetsEncrypt R3 [and I think ISRG Root X1, someone else will have to confirm/refute] was re-issued a few months ago. The original version(s) expired when DST Root X3 expired, but the updated version(s) expire in the future. Some clients hardcoded the original versions of the certs into their distributions, and manual installs/downloads may be out of sync. So for non-android devices, you have to ensure all the certs you're using - with the exception of DST Root X3 - have the future expiry dates.
Isn't that the same as the current shorter/alternate LE trust path?
May be, however when I attempted to use the command line option, it did not produced certificates using the self signed X1, so I did by hand. Perhaps I did it wrong. Perhaps I should issue one on the test LE to retry, but as I was in a pinch last night, just got this out of my plate to call it a day.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.