Thank you very much for the feedback! Happy to hear that you found an fixed the bug.
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?
might want to modernize your terminals, windows 7 is now over 16 months out of support
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?
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.
I tried to check the CA chain for the domain
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?
Thanks in advance!
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.
Thank you for the quick response and clarification!
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.
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:
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.
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.
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 ...)
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.
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.
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.
Not to worry, my friend. September 31 will never arrive. October 1 will though, so, maybe not.
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.
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.
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.
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...?