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 ?
Welcome to the Let's Encrypt Community 
This contains the information you seek:
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 ?
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.
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.
I never heard it was possible to manually build our own chain. Is there a tutorial explaining how to do it ?
It's pretty easy.
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
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.
@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 ?
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.
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 ?
See the explantation of @Osiris
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 ?
You've got it right. 
@griffin : Thanks a lot for your support!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.