Correct.
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.
Correct.
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.
Your ACME client can list all the chains it has received, once a certificate has been issued, but generally I don't think they have good support for this.
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..
Correct
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.
It doesn't need to be an ACME endpoint/option, or could also be a static file just like / or /build are.
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.
{
"availableRoots": [
"RSA": [
["DST Root CA X3", "https://letsencrypt.org/certs/isrg-root-x1-cross-signed.pem"],
["ISRG Root X1", "https://letsencrypt.org/certs/isrgrootx1.pem"],
],
"ECDSA": [
["ISRG Root X1", "https://letsencrypt.org/certs/isrg-root-x2-cross-signed.pem",]
["ISRG Root X2", "https://letsencrypt.org/certs/isrg-root-x2.pem"],
],
)
]
}
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.
And as a fail-safe equivalent of that...
Case "0": Use current primary/default chain
Case "1": Use alternate chain [#1]
Case "2": Use alternate chain [#2]
ISRG Root X2 will be available as a chain option next week, with (STAGING) Bogus Broccoli X2 being deployed earlier today.
Very cool
A tip for those who use the SSL Labs scanner at SSL Server Test (Powered by Qualys SSL Labs)
their production scanner still doesn't like X2
but their dev scanner at SSL Server Test (Powered by Qualys SSL Labs) has supported it since November
they haven't updated their production server in ages so I use their dev server for everything (it has a number of other updates and fixes such as support for IPV6-only sites)
GitHub issue: ADD ISRG Root X2 · Issue #904 · ssllabs/ssllabs-scan · GitHub
Seems like the change has been implemented, I was able to get an E1 certificate with a chain.pem that's only 1021 bytes compared to 2599 before. Thank you very much!
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.
The shortest chain does not include X2 at all.
It's just leaf and E1. (X2 comes from system stores)
And the only chain where you send X1 is the one using DST Root X3 as a trust anchor.
Thanks. I forget that. I do too stuff on the commandline (where you have to pass in the root cert as well) and often forget about that.
Hi,
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!
request certificate with for certbot
--preferred-chain "ISRG Root X1"
Or, if you're not using certbot:
Link: rel="alternate" headers in the response to (1)Currently this will be the alternate link which ends with /2, but you cannot rely on that so you have to download and parse all of the options.
Other ACME clients might also have chain selection options.
at long last, the main SSL Labs tester now fully trusts X2
https://www.ssllabs.com/ssltest/analyze.html?d=valid-isrgrootx2.letsencrypt.org