In general, we don't actually have enough information to tell this. :-) Consider the case of an older Android client (not from TFA, but bear with me), using ce

In general, we don't actually have enough information to tell this. :-) Consider the case of an older Android client (not from TFA, but bear with me), using certs from Let's Encrypt: https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/ On an older server install, it could be the server was setup with a manual R3->leaf trust, serving (at the time) both copies of R3. This would've been within TLS spec: https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2 https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2 as you are within rights to omit roots: > a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. Both ISRG Root X1 and DST Root CA X3 are well-known roots, and so might be omitted by an operator. ACME does its thing, but this (admittedly misconfigured) server only updates the leaf cert. However, original copy of DST->R3 expires. While we have two intermediates in the served chain, because our client relies on the DST trust root, it can't validate it because the cross-signed ISRG Root X1 is missing. But when browsing to a correctly-configured LE-based server (serving the cross-signed ISRG Root X1), this will prime the intermediate cache and allow validation to succeed. And from the PoV of the old Android based client, this would look like an intermediate is missing (because it doesn't trust the self-signed ISRG Root X1 but does the cross-signed copy). My 2c, but its entirely plausible (with public CAs) that this could be the case if one of these installations is out of date.