Although you can request the longer chain you should consider whether this approach (actively extending a legacy dependency which has a known impending expiry/failure) is a potential risk to your business continuity.
If you have a serious known dependency on the long chain you need to start to fix that now, because it's going away in less than a year. If you don't have a serious dependency on the long chain then consider changing now to test your assumptions and quantify the impact. If you don't know, then you need to find out.
Further to that point, while Let's Encrypt community members will probably not routinely specifically recommend a different ACME CA, if you happen to have a particular client base or device/application that has trouble as a result of the upcoming expiration event, it might be that Let's Encrypt won't be an appropriate CA for your needs after that event, in which case you may want to have a plan to switch to a different CA.
There are fortunately now several ACME CAs that provide services somewhat similar to Let's Encrypt's and that are compatible with the same clients. This was a hope and a goal of the people who created the Let's Encrypt project, and it seems to be working out. The switching costs are relatively low, although no other CA's offerings are exactly identical to Let's Encrypt's. While the ISRG roots are now widely supported and the vast majority of Let's Encrypt users will probably not see any major loss of compatibility after the upcoming expiration events, those who decide it's a particular problem for them will also have other options—and that's a great testament to the technology that the Let's Encrypt community has created.
But Boulder only serves a X2 chain cross-signed by X1, right? As far as I know (but can be incorrect here) it doesn't offer an alternative chain with the self-signed X2?
It's not too difficult to manually set a chain with self-signed X2 though.
If you're going to start offering an alternate chain for Root X2 not signed by Root X1, I'd recommend keeping it, its timing, and its messaging completely separate from the messaging discussed here of the "regular" chain changes.
Yes, while the names are completely fictional and different, the suffixes like "X1" represents the corresponding "production" certificate.
You can read (a little bit) more about the staging certificate hierarchy at Staging Environment - Let's Encrypt. While not named in that document, there also exists a "X3" root cert in production corresponding to the now-expired DST Root CA X3 root cert.
They're not offering it yet, but they may offer it as an "alternate" at some point (not related to the topic of this thread about changes to the default chain for certificates signed by R3).
You can configure your server to remove the last certificate in the chain if you don't want it to send the X2-signed-by-X1, and any client that has X2 trusted will be fine with it. There's just no way yet to have your ACME client create that chain file itself automatically.
I'd recommend to check the certificate due for removal first if it's really the cross-signed X2 cert. Because if you'd hardcode simply removing the last cert of the chain, then OP will get in trouble if the default chain changes to the short chain.
I want to make sure I'm understanding correctly... since my RSA certificate is already using preferred_chain = ISRG Root X1, nothing will change for me on February 8th? After February 8th, should I remove the preferred_chain (since it'll no longer be doing anything at that point) or leave it in place? Or does it matter?
And nothing will change with my DSA certificate, right?
And a more general question, is there a way to query what "preferred_chain" options an ACME server supports?
