Certbot still send expired CA certificate

[Nummer378]

@Nummer378

Let's Encrypt serves a chain up to the (now expired) DST Root CA X3, because that helps with Android compatibility. The current plan is to serve this chain until about 2024, though those plans may change at any time.

Most clients should have no problem with either chain - ISRG Root X1 is included in the current chain, and any validation algorithm following RFC4158 (and having ISRG Root X1 in the trust store) will use that as its trust anchor.

There are some clients - especially older versions of non-OS/non-browser related TLS implementations (OpenSSL, GnuTLS and others) that do not implement RFC4158 correctly. Those clients can verify the alternate chain, but not the default*.

For these clients, there are sometimes client-side workarounds available (removing the expired root from their trust store, enabling optional features....). Serving the shorter alternate chain server-side is a valid workaround server-side, but will break Android < 7.1.1.

*Assuming that ISRG Root X1 is in their trust store. Clients where this does not apply usually have issues with either chain, unless they ignore the expiry of DST Root CA X3 and the server serves the long chain.

Conclusively, both chains have advantages- and disadvantages. There is no solution for everyone.

The decision to serve the long chain (ending in the expired DST Root CA X3) was made, because the team believes that this will help the most users (those surfing to the site on their mobile devices). Other TLS implementations are generally more used by scripts, devops etc - not end users. Browsers in general will have no trouble with either chain, unless the (OS) trust store is out of date - in that case, neither chain works (except for systems that ignore the expiry of DST Root CA X3, e.g. Android).