Issue certificate using the IdentTrust « old chain »

Hello community,

Since May 10th we started having certificate with new certification chain (ISRG Root X1 -> R3 -> mydomain.com). We have a lot of connected IoT that are sensible to certification chain changes.

Is it normal ? I have been reading official communication that said it will start only at the end of June.

Can I use --preferred-chain parameter with certbot to use the "old chain" ? If yes, what is the value of this parameter ?

1 Like

Welcome to the Let's Encrypt Community :slightly_smiling_face:

This contains the information you seek:

1 Like

Thank you for your quick reply.

I cannot find it written clearly, but if I undertand correctly, their is no way to use the « old chain », only new « default chain » and « alternate chain » are available ?

1 Like

You are correct. The default and alternate chains currently available both have leaf <- R3 <- ISRG Root X1. For the default chain, the ISRG Root X1 is actually signed by DST Root CA X3 and included with R3 and your certificate when you have a certificate issued to you.

This may help though:

The current:
R3 signed by ISRG Root X1 signed by DST Root CA X3

is actually just a two-certificate CA chain of the previous:
R3 signed by DST Root CA X3

If you can't get the two-certificate CA chain to work, you could just construct the "old chain" yourself (manually or via script) by including your leaf certificate and R3 signed by DST Root CA X3. This is effectively "pinning" the old R3 intermediate certificate.

1 Like

While not recommended it's always possible to build your own chain. The cross-signed R3 intermediate is valid until Sep 29 19:21:40 2021 GMT. After that date, there is no other option than described above any longer.

1 Like

I never heard it was possible to manually build our own chain. Is there a tutorial explaining how to do it ?

1 Like

It's pretty easy.

  1. Get your new certificate chain issued from Let's Encrypt
  2. Put only the first certificate in the issued chain (your leaf) and the R3 certificate signed by DST Root CA X3 to which I gave you the download link (@Osiris's link is informational, while mine is the actual R3 certificate itself) in a single file with your certificate first

With just those two steps, you have constructed the old default chain.

New Default Chain Issued from Let's Encrypt:

your leaf certificate signed by R3

R3 signed by ISRG Root X1

ISRG Root X1 signed by DST Root CA X3

Old Default Chain You Build Yourself:

your leaf certificate signed by R3

R3 signed by DST Root CA X3
3 Likes

Do note that this is not recommended, as the intermediate used to sign your certificate could change any moment and without any notification what so ever. I.e., the intermediate R4 could suddenly be the signing intermediate in case of an incident with R3. Would such a thing happen and you'd still be providing your "manual" intermediate, the chain send by your server would be incorrect which could lead to errors in browsers.

IF you decide to manually provide a chain as described here you either accept the risk of a broken chain in the event of a change in signing intermediate by Let's Encrypt or even better you should write some kind of script which rebuilds the chain used by analyzing the leaf certificate issued by Let's Encrypt.

2 Likes

@griffin : Thanks a lot! I've just tried it and it works perfectly.

@Osiris : You talk about error in browsers, but in our case (IoT device that embed root certificate), is it problematic ? What is the probability that the intermediate certificate change ?

2 Likes

Hi @rjs

never hardcode intermediate certificates, that's a simple rule.

Browsers are tolerant, they add the chain. Other clients are critical. They may fail.

So if you have IoT you should always import the intermediate of your newly created certificate.

Especially IoT devices are at risk of being completely locked out, we've seen that on this Community when the recent intermediate change happened.

Unknown, could never happen, could be tomorrow.

2 Likes

A post was split to a new topic: Never hardcode intermediate certificates

2 posts were merged into an existing topic: Never hardcode intermediate certificates

I apologize but I’m a bit confused.

I wrote « IoT device that embed root certificate ». But we don’t embed intermediate certificate in our IoT devices.

So if the intermediate changes, what is the probem ?

1 Like

See the explantation of @Osiris

1 Like

Downloading the previously-used intermediate certificate (R3 signed by DST Root CA X3) and constructing your own old "default chain" should only be used as a temporary fix if you cannot immediately get the current "default chain" (as issued by Let's Encrypt) working. That temporary fix effectively "pins" the old R3 intermediate while ignoring the new R3 intermediate being sent with your certificate by Let's Encrypt. This works for now, but as many have warned in this thread, this will immediately break if Let's Encrypt starts signing RSA certificates with a different intermediate certificate for any reason. Please take the time now to fix the devices as necessary to utilize the three-certificate chain if at all possible.

If it happens we could use the same « manual temporary fix » with the new intermediate certificate used by Let’s Encrypt or I am misanderstanding something ?

1 Like

You've got it right. :slightly_smiling_face:

1 Like

@griffin : Thanks a lot for your support!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.