This is actually a fairly complex topic with lots of pros and cons: How strict shall one validate expiry dates? Expiry dates are important, because expired certificates might have been compromised. This is increasingly likely the older the cert is. For example, very old (root) certificates existed with 1024 bit RSA keys (or even 512 bit RSA). We are now at the point where those can be factorised and no longer provide authenticity. Luckily these certificates are largely blocked and removed from systems. For leafs we don't know if this certificate has been replaced, and the old one has been compromised or not. So for an expired certificate, authenticity is no longer ensured - one of the three goals of TLS.
The question is now, should one continue and potentially gain confidentiality and integrity, even if authenticity is broken? In the vast majority of cases, no active attacker is present and we would still have these two goals. Operating in this kind of fashion is a subtype of "Opportunistic encryption" and is for example largely used in E-Mail.
Using plaintext (HTTP) on the other hand makes it absolutely clear that no security whatsoever is assumed. This can be a good thing, so no party assumes the connection were secured. For example, if a TLS handshake was continued after authenticity was broken, the server might not be aware of this and send confidentional information it wouldn't have send otherwise. Granted, this is rare in the common web setup. More common might be that the user enters sensitive information under the assumption that the connection were confidential and authenticated while in fact it was not*.
*An example for this is the IMAP(s) protocol: Some IMAP servers forbid sending passwords if the connection is not currently using TLS (e.g STARTTLS hasn't happened yet).
Ubuntu 14.04 LTS ESM, 16.04 LTS ESM, 18.04 LTS, 20.04 LTS, 21.04 have all been fixed and will not be affected by DST Root CA X3 expiry. All letsencrypt servers should continue to work with OpenSSL, GnuTLS, web-browsers, with either default long chains (default config), or the short CA chains.
Make sure all updates are installed and carry on.
For 14.04 & 16.04 one does need ESM enabled to get access to these updates.
I understand that LE has replaced ISRG-X1 cross-sign with a version that was re-signed to an expiry date after the signing root's expiry date.
I understand that older android devices are happy with this.
What I am unclear of:
Everything reads as if LE will still keep the chain to the expired root as default, is this correct?
What happens to the clients that are not older android devices? Do they typically short-circuit to the ISRG root, or is there some interplay with the recent OpenSSL patches?
Reading some of the OpenSSL patches and tickets on various projects/systems, it sort of reads like the community decided to essentially break OpenSSL to support LetsEncrypt. Is this right?
That is my understanding, yes. At least until the cross-signed ISRG Root expires in 2024 (or telemetry/stats make it seem like it's no longer necessary).
As I understand it, most modern devices that already trust the ISRG root will either short circuit to it or dynamically build an alternate valid chain that ends with the self-signed root instead of the cross-signed one. In the legacy Android case and similar, they simply don't care that the root is expired (as opposed to an intermediate).
I haven't been following the OpenSSL stuff too closely, but I didn't get the impression that anything in OpenSSL was being broken. I thought they just added a feature that would allow alternate chain building. For versions that are too old to support the new feature, they're just taking advantage of how the code already works when they suggest removing the DST Root from the trust store.
Most clients stop their chain building when reaching R3-signed-by-ISRG Root X1, as the signing keypair is in their anchor trust store. But: OpenSSL pre-1.1 (i.e.: 1.0.2) does NOT behave like that. So the standard chain with the cross-signed ISRG Root X1 added to the certificate chain is working for almost every client, modern clients and older Androids. Except for certain OpenSSL versions due to their chain building logic.
That isn't really necessary. The only thing required for affected OpenSSL clients is deleting the soon-to-be expired trust anchor from the root store. That will "bypass" the "problematic" certificate chain validation logic. That would be option 1 from the workarounds presented by OpenSSL themselves.
Yes and no, this depends on your OpenSSL version. OpenSSL versions < 1.1 can have trouble with this chain, because they don't support "short circuit". OpenSSL 1.0.2 has workarounds available, < 1.0.2 not. 1.1 and higher have no issues at all.
This is not only an OpenSSL problem. Other smaller TLS libraries - for example LibreSSL, GnuTLS and embedded TLS implementations often have the same issues. TLS stacks from operating systems and browsers on the other hand do not have these issues.
This workaround relies on the presence of a feature OpenSSL calls "partial chain". This is available only in 1.0.2 and higher. I do sometimes see 1.0.1 (or even older) OpenSSL versions in the wild, where this workaround won't work.
In an ideal world we would all have up-to-date software. That would also mean that no one runs outdated Android and we wouldn't need this hack with using an expired root certificate. Sadly this isn't how the world works.
OpenSSL is a userspace library, so I wouldn't count that as operating system stack, unless it's really used by the OS itself (this is for example the case with Android, where BoringSSL is the de-facto OS implementation).
Operating system TLS stacks are for example Linux Kernel TLS*, MS Windows Schannel, macOS Secure Transport.
*This is a bit special, because I've heard handshakes (and control) (can) run in user space.
OpenSSL has been historically strict, so it was surprising to see the "short circuit" behavior introduced in newer versions and backported to legacy versions.
