Extend cross-signed by IdenTrust’s DST Root CA X3 signed certs

Help
1

We run an IoT service on https://mdash.net domain, which uses Let's Encrypt for keeping its certs auto-updated.

Many of our clients still use CA certs cross-signed by IdenTrust’s DST Root CA X3.
The recent update made them all disconnect, due to Shortening the Let's Encrypt Chain of Trust - Let's Encrypt

May we ask for the extension until the 6 Jun deadline, in order to let our customers to update their CA certs to ISRG Root X1 / ISRG Root X2 , please?

Thank you.

2

Until 2024-06-06 you can use the alternative chain provided by the ACME server. Assuming your ACME client supports that.

From 2024-06-06 till 2024-09-30 you'd have to hard-code the long chain yourself, as it won't be provided by the ACME server any longer.

After 2024-09-30 18:14:03 GMT the cross-signed intermediate will be expired and there are no more options down that road.

5 Likes
3

Your nginx server is still using the longer chain. From a cert issued Feb1

None of your clients should have been disconnected from the Feb8 change as you won't be given the shorter chain until your next cert renewal.

What ACME Client are you using to get your certs? If it supports selecting the alternate chain you should do that for any renewals before Jun6 and then do a renewal just before Jun6 (you may have to force it once to make it happen early).

3 Likes
4

They did renew a few days ago, probably with the short chain as that's the default. I think they reverted to the old certificate with the old chain.

2 Likes
5

Yes they did update to the shorter chain, and we reverted it back.

We use certbot 2.10.0, apparently the --preferred-chain "DST Root CA X3" makes a long chain with X3, I think that should work.

Thank you for your attention, appreciated.

3 Likes
6

Please note that this is just a temporary workaround and you have less than half a year to update the IoT devices.

1 Like
7

@Osiris thank you.

Yes we're fully aware of that. We encourage our customers to update ASAP, and will trigger deliberate roll-forwards to the short ISRG Root chain periodically to catch those who fail to update.

5 Likes
8

Hopefully they'll do that within two months, as I would not recommend hardcoding the long chain between 2024-06-06 and 2024-09-30. While certainly possible, it would probably require some scripting and you'd need to make sure the hardcoded long chain will be replaced by the short chain before 2024-09-30, which would probably require second manual step.

9

Quick question.

What would be the best way to test clients against the short chain?
I can see that Chain of Trust - Let's Encrypt has test websites with the valid/expired/revoked certificates.

I am using this openssl command with the old ca.pem against the "valid" website, and it succeeds:

openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443 -servername valid-isrgrootx1.letsencrypt.org  -CAfile old.epm | openssl x509 -noout -dates

I am expecting it to fail, but it succeeds. What do I miss?
Is valid-isrgrootx1.letsencrypt.org signed with a long or short chain?
What's the right way to test clients against the short chain?

Thank you!

1 Like
10

Please remove the latter part (after the pipe) and check the output. I'm getting a "Verification error: unable to get local issuer certificate" warning in between all the other output. OpenSSL will simply continue despite the error, but piping the output to the second openssl command "eats" all those previous outputs, including the error.

The s_client application is more for debugging than anything else, so it'll continue no matter what.

3 Likes
11

that's using short chian

4 Likes
12

.epm OR .pem ?

2 Likes
13

Hi all, I'm also trying to test a cert I'm using as part of the platform cpq mentioned.
The cert I'm trying to validate is this one.

I download the file and name it x3-based-ca.pem, then test with the following command:

openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443 -servername valid-isrgrootx1.letsencrypt.org  -CAfile x3-based-ca.pem

the output I see is:

---
SSL handshake has read 3299 bytes and written 433 bytes
Verification: OK
---

Since its x3 based I was expecting it to fail but it didn't. Have I done it wrong or is this cert short chain valid?

14

The CA bundle you referenced includes ISRG Root X1, so that will validate fine. Path validation very much depends on the operating system and the software libraries being used so really to tell if something will validate you need to test on the client device. e.g. Old android tolerates the expired DST Root CA X3 just fine (even though it expired years ago), but Windows most definitely does not.

4 Likes