Currently, the acme-v02.api.letsencrypt.org endpoint sends the pre-May-4-default leaf ← R3 ← DST Root CA X3 chain when an ACME Client connects to it. (Trying to be clear here: I'm not talking about the chain returned to an ACME Client for use in configuring a web server, I'm talking about the API itself, used by the ACME Client to talk to Let's Encrypt, like what happens when you run openssl s_client -connect acme-v02.api.letsencrypt.org:443 or curl https://acme-v02.api.letsencrypt.org/directory or the like.)
Will that change to the "long" chain at some point, of leaf ← R3 ← ISRG Root X1 ← DST Root CA X3? This is probably a non-event for most ACME Clients, but may be good to be aware of when it happens just in case some client somewhere doesn't like it.
As @Nummer378reminded me of in the other thread when I asked about it (I thought I'd seen it somewhere but couldn't remember where), if I understand the current plan correctly, at some point the API endpoint will switch to the "alternate" rooted-in-ISRG Root X1 chain. Do we have a rough timeline of when that might be? I'm guessing it should be at some point in the next few months?
I feel like the impact of this would be felt as a ripple through whatever library/mechanism the ACME client is using. For instance, my ACME client CertSage uses the PHP cURL library, which is where the point of pain would originate if CertSage were to suddenly start behaving wonkily. I mention this distinction because a point of failure of any standard mechanism could cause a domino of client failures, especially within any given language/OS realm.
Like I said, moving to a longer chain is probably a non-event. I can imagine a scenario where it'd matter, like an embedded system with limited resources generating its own certificates that runs out of memory because the chain is longer, or an old corporate firewall misbehaving. I don't think it needs to be shouted from the rooftops, but it ought to be listed somewhere so it doesn't take anyone by surprise.
Having the API switch to being rooted at ISRG Root X1 is also probably a non-event for most people, but it wouldn't shock me if some poor system somewhere is set up to connect to the API with a command line that only trusts DST Root CA X3.
Now that you mention it, I'm not sure what the trust store on my shared hosting instances with GoDaddy even looks like. I'm assuming/hoping that the cURL installation is handling the trust store, but I'm not sure that I even have reasonable access to find out. You could be on to a bigger issue than you might be thinking as the trust stores on the many hosting platforms out there may be considerably more questionable than what is found in the average browser of an end user.
Just like on consumer platforms, usually whatever OS you use has a trust store built in which is probably reasonable. Many Linux-based distributions use a ca-certificates bundle from their package manager, which is often based on Mozilla's trust store. (Though Mozilla gives lots of warnings that their trust store is only intended and vetted for use in Mozilla software.) Probably most OS trust stores would have ISRG Root X1 built in, or if not then they're also missing tons of other security updates.
My thinking is that problems would crop up with systems more along the lines of some homegrown or lesser-used ACME client (again maybe on an embedded system), which does an equivalent of curl -cacert dst-root-ca-x3.pem … where they hard-coded the root because their platform didn't have a trust store available (or they didn't know how to use it). Of course maybe they just switched to using curl --insecure … instead.
It's reasonable to expect trust stores to be up to date but inevitably many won't be. A user contacted me with an issue a few days ago, turns out their server trust store (on Windows Server 2012) was significantly out of date. Obviously Windows normally keeps that sort of thing up to date but there will be administrators who suppress that either on purpose or accidentally.
I personally have (almost) zero sympathy for internet connected systems that are not appropriately updated or maintained, but I'm sure others are more forgiving - yes it can be someone else's fault that it's not up to date, but the buck stops with the administrator/owner.
Well, Windows specifically does this interesting lazy-loading approach where you won't see roots in the trust store when you look but it knows to download them on-demand from Microsoft when needed by a browser. So "is the trust store up to date" is harder to answer on that platform.
But yes, systems need to be updated with latest security updates, and that includes updates to the trust store. (Which means I find completely bizarre that old Android devices don't get updates but somehow are safe to use on the Internet.)
In any event, with the ACME API endpoint specifically, I suspect the problem is more likely around systems that don't use their system's trust store correctly, or like I said embedded/IoT-type systems that are as bare-bones as possible.
Thanks, yes it is unpredictable but doesn't have to be as standard Windows Update will also populate this (since Vista/Server 2008). However, windows update is restricted on many systems and the trust store (and the lazy path validation method mentioned) can be limited by group policy, also windows update config can get messed up sometimes.
- yes it can be someone else's fault that it's not up to date, but the buck stops with the administrator/owner.