Let’s Encrypt comes up with workaround for abandonware Android devices

For example take a 90 day Let's Encrypt certificate. When it was issued ISRG had recently (likely seconds earlier) verified that the subscriber apparently had control over all the names listed.

Suppose a month later one of the names has been sold to you. You're entitled to have that certificate revoked. Since you control the name, you can just do the Let's Encrypt proof-of-control dance and get it revoked, issue a new one instead, whatever you want.

They issue millions of certificates every day, so they don't want to remain indefinitely responsible for the ones from last July, from 2018, and so on. Ninety days later, having expired, ISRG has no opinion about whether the holder of the certificate still controls those names, and if you call that revocation API it will refuse, there isn't anything to revoke because it has expired.

Now, if the certificate you're shown is 15 seconds expired, is it so much more likely that it's really because they don't control this name any more than it was a minute earlier? Not really, but we must draw a line in the sand somewhere, or else a 10 year old certificate for "www.microsoft.com" is still valid right?

For the root the argument is a bit trickier, after all they could just issue themselves a new certificate with the same keys but a different expiry date - and some root CAs have done this in the past.

In this case (for roots) as we see with Android not every system actually enforces expiry. Out of the box OpenSSL doesn't for example I think. But the argument as to why expiry matters for roots goes like this: If we are actively managing the trust store, clearly a trusted CA which wants us to continue trusting them should send us a new or updated root in plenty of time. If they forgot we can hardly have confidence in their other processes. If they decided not to we certainly should cease to trust their root when it expires as this signifies they presumably do not intend to obey policy any more, for this root at least.

For example, if you have a Firefox that you just decide not to ever update, I believe it won't enforce expiry of roots. Newer Firefox builds will, like clockwork, remove expired roots entirely. But the old build will continue to trust roots that have notionally expired if you are still running it.

This is the key issue. For a long time there was no working revocation mechanism. With a combination of OCSP, OCSP stapling and the muststaple extension you can get there, but this isn't in widespread use yet. Revocation is a difficult problem.

That's a meaningful distinction. Certificates which lack SCTs (the proof that they were shown to Certificate Transparency logs before you) don't work in some popular browsers, but those certificates are not policy violations, they just don't work in browsers so you probably should not use them on a web site. In a handful of cases such certificates exist for legacy reasons (e.g. industrial environment that doesn't know anything about the "Web"), in other cases they're minted but not intended to be seen yet, for example Google's front end facing systems can do this.

When Google accidentally made some of those certificates live with insufficient SCTs they just did not work in Chrome - which is embarrassing but it was not a policy violation, the subsequent root cause analysis was Google's choice not mandated by the other root trust stores and there was no threat that anybody's trust would get revoked.