Thank you very much for the feedback! Happy to hear that you found an fixed the bug.
7 Likes
We have a bunch of Windows 7 SP1 embedded terminals that does not have any updates since SP1 package, they are today accepting the Let's encrypt certificates will they be affected after September 2021?
Br,
Mattias
2 Likes
might want to modernize your terminals, windows 7 is now over 16 months out of support
1 Like
We are working on that as well and new terminals are not shipped with the same configuration, do you have any input on the question?
3 Likes
Well, according to the Certificate Compatibility page, anything XP SP3 or newer should work, as long as it's been getting the root certificate updates.
Can you run code on the devices? If you can connect to https://valid-isrgrootx1.letsencrypt.org/ in whatever program you're running on there, and then see that ISRG Root X1 is in the Windows Certificate Manager as a Root Certificate (assuming that's the trust store your application uses), I think you'd be alright, but it may be hard to test everything for sure.
9 Likes
I tried to check the CA chain for the domain https://valid-isrgrootx1.letsencrypt.org/ using crt.sh/ but I could see R3 had a DST Root CA X3 in the parent CA field (along with ISRG)
Therefore, this domain seems to have a cross signed certificate? or Am I reading it wrong?
If i'm not wrong, you anyone point to a domain which is using the alternate certificate chain?
Additional references to this page in the image -> crt.sh | valid-isrgrootx1.letsencrypt.org, crt.sh | CA:183267
Thanks in advance!
3 Likes
There are two versions of the R3 intermediate. The cross-signed version and the ISRG Root X1 signed version.
Cross-Signed Version: crt.sh | 3479778542
ISRG Root X1 Version: crt.sh | 3334561879
This approach cannot work. crt.sh is a CT aggregator. This service sees only what certificates were issued, but it does not know which chain was actually send by the service. You searched for who issued certificates for valid-isrgrootx1, and you saw that Let's Encrypts R3 intermediate issued certs for this domain - this is all correct.
However, crt.sh cannot know which version of the R3 certificate (they're both using the same keypair!) was used, so crt.sh has to guess here.
In order to retrieve the certificate chain, you need to connect to the service and see what is actually send by the server. This can be done using one of many different tools, e.g openssl:
# openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443
CONNECTED(00000184)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = valid-isrgrootx1.letsencrypt.org
verify return:1
---
Certificate chain
0 s:CN = valid-isrgrootx1.letsencrypt.org
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
As you can see here, the service valid-isrgrootx1.letsencrypt.org sends the chain "leaf -> R3 -> ISRG Root X1", as it sends the R3 intermediate signed by ISRG Root X1.
10 Likes
Thank you for the quick response and clarification!
5 Likes
Hello community,
is there a way to stuck with DST Root CA X3?
We are using letsencrypt with certmanager, but even specifying
preferredChain: "DST Root CA X3"
we obtain certs with only ISRG Root X1 as issuer.
We are encountering compatibility problem with some old devices.
Thanks
3 Likes
These are the two current chains:
-
Default chain: End-entity/leaf certificate (sig R3) ← R3 (sig ISRG Root X1) ← ISRG Root X1 (sig DST Root CA X3)
-
Alternate chain: End-entity/leaf certificate (sig R3) ← R3 (sig ISRG Root X1)
As you can see, neither R3 intermediate is signed by DST Root CA X3 and both chains include ISRG Root X1.
If you want the R3 intermediate signed by DST Root CA X3, you can download it here:
https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem
Pinning/installing that intermediate and using only your leaf certificate served by Let's Encrypt will work for now, but you should do whatever you can to try to move forward.
You can construct the old fullchain.pem by putting your new leaf certificate followed by the intermediate downloaded from the link above in a single file.
8 Likes
Since we're now slightly under 90 days until the self-signed certificate for DST Root CA X3 expires, I built a test site https://letest.tlrmx.org/ which behaves exactly the same way most web sites using Let's Encrypt will behave, but has conveniently not expired until just after DST Root CA X3 does.
This means if you can trick your software or hardware into believing it's now just after DST Root CA X3 expires, it will believe that root certificate has expired, but the certificate for letest.tlrmx.org has not. If your system considers that this situation is OK, it should continue to work after the end of September 2021. However, if the system under test reports a certificate expiry then that's a problem and you should begin planning for it now, while you still have about 90 days to develop and test a workaround.
On a Linux system for example, we can use the faketime tool to tell the program curl that it's October 1st:
faketime '2021-10-01 UTC' curl https://letest.tlrmx.org/
NB This idea will stop working on October 1st, but by then you will have any problems for real, so such tests will no longer be very useful.
6 Likes
Hello
Following a hardware migration and renewing (using dehydrated) my certificates last weekend, I was facing a big problem.
Using the staging environment, all of my certificates were renewed correctly, but with the expired root certificate "durian root ca X3".
Switching to the prod environment, everything went fine again ... but now I'm concerned about the expiration of DST Root CA X3.
I'm looking for what to put in place to protect myself from a disappointment on September 31
I cannot switch to certbot because it is not compatible with my linux distribution (Debian 7 .. yeah ... I know ...)
Thank you
2 Likes
Welcome to the Let's Encrypt Community 
If having a functioning ACME client is your biggest concern, there are several solutions for that.
I've also authored my own ACME client (CertSage) that isn't listed there yet. It is a single file that only requires your webserver to have functioning PHP.
4 Likes
And if your issue is with the default chain presented by Let's Encrypt, dehydrated supports the --preferred-chain option so you can choose a different chain from the chains offered by the Let's Encrypt end-point.
4 Likes
The only difference between the default and alternate chains at present is that the default chain expects DST Root CA X3 to be in the trust store while the alternate chain expects ISRG Root X1 to be in the trust store. Since both chains at present include ISRG Root X1, if ISRG Root X1 is already present in the trust store, either chain could be verified, regardless of the presence of DST Root CA X3 in the trust store. So, the way I see it, being able to select the alternate chain does not offer any additional compatibility whatsoever. You either have ISRG Root X1 in your trust store or you don't.
5 Likes
Not to worry, my friend. September 31 will never arrive. October 1 will though, so, maybe not.
8 Likes
This is only true for the present, but not after DST Root CA X3 has expired. After that there will be clients that have trouble with the default chain, but will have no problems with the alternate chain.
6 Likes
I would think anyone with ISRG Root X1 in their trust store would have no problems with either chain. Am I missing something?
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.
Without that, I agree that the alternate chain would be needed.
4 Likes
There are quite a few TLS implementations out there (mostly non-browser things: Older OpenSSL, GnuTLS, LibreSSL...) that will always validate up to the highest certificate in the chain:
The behaviour mentioned above applies for example to OpenSSL < 1.1, < mid-2020 GnuTLS & LibreSSL and probably over two dozen embedded TLS implementations.
6 Likes
I wonder what would happen if these clients removed DST Root CA X3 from their trust stores? Failure to verify or find an alternative chain of trust or...?
4 Likes