DST Root CA X3 expiry countdown

Encryption is now OFF

All of your personal information (and questionable browsing habits) might be publicly exposed.


I find it funny that some systems (and people) would rather use HTTP than HTTPS with an expired certificate in the chain. It's not like RSA (or EC or whatever) selectively and suddenly stops working when a certificate expires.


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).


Just to keep the tension, the expiry is now less than a week away!


I do expect a bit of breakage in the days and weeks after expiry... Hopefully not too much.


@Nummer378 It was probably meant as a dynamic image, right? Unfortunately, it has been cached by Discourse :stuck_out_tongue:


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.


Here's a video about this expiration! YAYYYY



Less than a day remaining!

I've got some surprise in the countdown for those watching in the final moments.


should I be nervous about this surprise :grimacing: :laughing:


Is it too late to add a sub-timer for the old DST signed R3 which is only like 4'ish hours away?

I started one here but it's only granular to the minute rather than the second. So when it expires, there will still be 40'ish seconds left.


Oh yeah I forgot this one expires slightly earlier.

Modifications to the DST countdown are probably a bit late now, but I could spin up a copy of the other countdown adjusted for R3, just for the lolz.


Done. Countdown to Let's Encrypts R3 cross-sign expiry


May I guess?

The page will redirect to a demonstration site where the old cross-sign certificate is used. People will see browser specific trust error page.


I'm actually confused a bit by all this myself.

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.

The things you're refering to is probably workarounds 2? See: Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2 - OpenSSL Blog


*to support older Android.

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.


I don't have a problem with that:

OpenSSL 1.0.1 is out of support since 1st January 2017 and no longer receiving updates.

Good reason to FINALLY update your exploitable libraries...


Which "TLS stacks" are you referring to? My Gentoo GNU/Linux operating system probably uses OpenSSL as its TLS stack?


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.