I need to keep using the current cross signed certificate chain as long as possible.
certbot's help says: "[...] prefer the chain with an issuer matching this Subject Common Name".
Will this do the trick ?:
certbot renew --preferred-chain "DST Root CA X3"
How can I check that this is working before January 11, 2021 ?
Try issuing a new cert in --staging.
Sorry: Staging can't replicate the change to the trusted chain.
I haven't tried this yet I must admit, but wouldn't the chain names be different in staging since that uses fake certificates?
They would. Unfortunately, I can't find the names of the new chain for the staging server
The secondary chain on staging currently rolls up to the root called Fake LE Root X2.
Makes sense @rmbolger, thanks 
Perhaps an idea to add it to the staging environment documentation.
You can also put the option into cli.ini so that you don't have to remember to pass the flag every time.
But will that lead to confusion/lack of support when --staging certs are being requested?
RE: @petercooperjr question:
There is no cli-staging.ini
The flag is only a hint to Certbot, not a requirement.
So when you request a certificate from the staging server and Certbot can't find a matching alternate chain, Certbot will just use the default chain that was sent.
The alternate chain from staging is only really useful as a tool for client developers anyhow.
@rg305 certbot will ignore the value of preferred-chain when it can't find the value in the alternate chains. I'm pretty sure that if someone wants to experiment with different chains on the staging server, they'll use the command line option --preferred-chain.
Although I'm not certain if the command line options are preferred above cli.ini, perhaps @_az can elaborate on that.
Edit:_az beat me to it..
So then we fail the original test (by using staging):
12 posts and no closer to a definitive answer.
On re-read: I guess somethings just can't be staged.
@rg305 Testing it on staging will prove the client can succesfully use the --preferred-chain command. It is obviously impossible to use the production command on the staging environment as the Common Names will always be different.
You'll just have to test your client and assume the CommonName for the chain is correct. 1+1=2.
Testing in staging is recommended so you know you've got a recent enough certbot. Would be a pity if you found out your certbot was too old too late..
So...
Then the answer to:
Is to use (brute) force?
certbot renew --preferred-chain "DST Root CA X3" --force
Why would you "force" anything @rg305? The current certificate is already chaining to `DST Root CA X3".. Just renew when the time comes will do fine.
How does that answer:
Please tell me there is a simple and logical answer.
There is: you can't.
You can only indirectly test it by testing your client for correct handeling of the chain by testing --preferred-chain on the staging environment and making sure you've got the correct CommonName for the IdenTrust root. I.e., don't make a typo.
Yes, the more I think about it, the more it becomes clear that this is a client side implementation.
And there is no present production way to alternate the testing.
Lord help us.
So many clients ..., so many ways for this to go wrong.
For the purposes of testing --staging --preferred-chain "Fake LE Root X2" will work, even if it's in cli.ini.
I posted the names of the chains earlier here.
The Certbot team had planned to make an announcement on how to prepare for the transition if you plan to use the legacy chain. That's what I linked 2 posts ago. I think it was supposed to come out at the same time as the Let's Encrypt post. Obviously that didn't happen and we're getting lots of posts about it now.
Ultimately you have to put some trust into the instructions it provides (when posted) because 50% of this change is on the CA side, so there is no perfect reproductive test.
Nah.. Most clients will just start using the ISRG Root X1 from January 11 on. That isn't wrong.
Personally, I don't think there is anything wrong with not supporting ancient OSses.. Probably filled with a huge amount of bugs, security issues, exploitable stuff et cetera.
