In the immediate future (earliest possible: today; latest possible: December 16th) we will begin issuance from our new R3 intermediate.
As usual, this will take the form of a phased rollout, beginning with us issuing a few certificates for ourselves, then allowing issuance in staging, then switching Prod to issue from R3. We will update this thread when these stages are in progress.
This change should be a non-event for you and your site's users. This is not related to the chain-switch coming up in January, and will not impact users on older operating systems. The R3 intermediate will still chain up to IdenTrust's DST Root CA X3 by default (with an alternate chain up to ISRG Root X1 available, the same as today).
There is one circumstance we are aware of in which this might have an impact: if your ACME client ignores the intermediate provided by our ACME server. In the ACME v1 issuance flow, clients are supposed to fetch the issuer certificate from the
/issuer-cert API endpoint after receiving their new end-entity cert. In the ACME v2 issuance flow, the issuer certificate is provided as part of the response from the
/cert API endpoint. If your client ignores these provided issuer certificates, and instead hardcodes or continues to rely on an old issuer cert, then users of your site may fail to validate your end entity certificate. It is also important to note that this failure may be intermittent: if a user's browser already has the R3 intermediate cached from a different site, they may still successfully validate your end-entity cert, despite your site serving the wrong intermediate chain. If you find that your site is serving the incorrect intermediate after receiving a new certificate issued from R3, you'll want to update your chain file, and also file a bug against your ACME client or report it here so we can work with its authors to implement the correct behavior.