Doesn't really matter. In the short term, it'll just be equal to the current default, thus doing nothing. Perhaps in the far future, it might interfere with a new default chain, but that would be announced too, just like this change.
As far as I know, this is not possible currently. It's not part of the ACME protocol specs, but that wouldn't mean it couldn't be added in the future.
Certbot at least currently doesn't. It only downloads the alternative chains if required by the preferred_chain setting and next throws everything except the selected chain away. You also can't switch chains afterwards, a new issuance is required. I opened a feature request in the past to store the alternative chains on disk, so you can select different chains after issuance offline, but the Certbot team is unfortunately very small with little time And thus this feature request was closed..
Well, eventually it will need to change to something else, since eventually ISRG Root X1 will even be expired, but it probably won't need to change for quite some time. If selecting a specific chain, though, I'd recommend watching the API Announcement category in order to make sure one knows when and if to change it.
No, one of many, many things where the ACME protocol doesn't actually expose the things to the client that the client needs to know about. In theory, each certificate issued by an ACME server can be from a different chain. (Which is kind of what happens now with the ECDSA allowlist.)
I would leave the configuration in place. It is possible that LetsEncrypt may temporarily revert changes during the migration due to deployment issue, which could lead to the wrong chain being served.
No. "preferred_chain" is a Certbot command that uses logic specific to Certbot. There is nothing in the ACME spec to advertise available chains - ACME simply shows a default chain and offers links to "alternate" chains. Certbot will download all the chains for a finalized "Order" and only save the best matching chain. Other clients may implement the concept of "Chain Selection" and "Alternate Chains" using different logic or options.
In a more perfect world, Certbot would have an option for this – as it is easy to pass in the wrong chain identifier. Unfortunately, the ACME spec (or LetsEncrypt divergences) would need to support advertising this somehow. IMHO, creating a new chainOptions endpoint to list current roots would be a good idea, but I don't see it happening due to the high priority of the items the ISRG team have in their backlog.
If it were to be part of the spec, so that all ACME servers would implement it, it would need to be a URL advertised on /directory somehow. The implementation could be a static file on any URL, not require post-on-get, etc – but it needs a link on /directory as an endpoint or within the "meta" payload so it can be properly discovered by clients. However, since the X2 ECDSA root is opt-in, and not only "not available to everyone" but also removes RSA support for an account enabled with it, it would make sense for this information to be in a post-as-get endpoint to show account-specific information.
A benefit of doing this, is the ACME RFC/ISRG could then influence and standardize how chain selection works across all clients by exposing select information. For example: the following payload would likely influence clients to make the chain selection happen based on the combination of key type AND commonName, instead of any other fields. IIRC, some clients had initially used fingerprints or other random fields. Making the selection on any other field(s) would require downloading and examining the roots – which is not something client authors are likely to implement.
Note: It would probably be best to list these as "availableChains" and show the full chain for each one - starting at the root and ending at the signing intermediate - but I only had a few minutes for this.
IMHO, you should not merely remove the X1 cert, but also replace the cross-signed X2 with the self-signed X2 (available from the LE website). Some clients (browsers, libraries, etc) might not be happy with a cross-signed X2 presented as the root and throw an error due to that.
We would like test the changes out in advance of the February 8th date. Is there any way we can do that? Would it be possible to get this set up on a per-account basis or have some way to get access to this change in a staging environment?
Ideally, we'd have 1-2 months to test out the change.
Please reply if you're also looking to do this. Thank you!