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

KaiOS and Tizen also have a userbase wide enough to be considered major consumer OS's (even if primarily targeting markets such as India).

The Switch OS could probably also be considered major at this point with the number of devices out in the wild. Same goes for LGs WebOS. VxWorks is also fairly big, although at least Canon changed over to something custom for their cameras.

And that's just the consumer facing OSs. There's a lot of surprising ones, like Apples use of NetBSD for their Airport devices.

OS diversity is high outside common desktops, and desktops are a vanishingly small portion of consumer computers.

iPadOS and watchOS deserve a mention.

Why are you going after Let's Encrypt and not the manufacturers and hardware vendors that abandoned the devices?

The source code for the device drivers are not available to be able to update these phones to the latest version of Android.

These devices are insecure. Using them is not sane.

I can understand the purpose behind the expiration dates on the SSL certificates you get issued for your domain — domains change hands, things happen. But why do root certificates have to expire at all? Relying on the system to be updatable and requiring constant maintenance doesn't feel very sustainable, and generally causes all kinds of problems. Modern Android versions treating user-installed root CAs as second-class don't exactly instill confidence either.

It's also important to see that the SSL/TLS system does not allow you to revoke a certificate with 100% certainty, the revocation mechanism is flawed - it's often practically impossible to reliably revoke a certificate after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability.

* CRL is a list of revoked certificates, it must be downloaded and manually applied to all clients, which only occurs once in a while as a new update, and many hate system updates. The huge lists of revoked certificate have size, performance and scalability problems, currently they are considered obsolete and mainly replaced by OCSP.

* In OCSP, clients ask a CA's OCSP server to determine the validity of a certificate. It operates out-of-band from the main TLS connection, and networks and CA servers are not reliable, especially in the early days. Timed out OCSP requests were common. If you are a web browser, you don't want a failed OCSP request to block/DoS HTTPS, thus OCSP becomes essentially "optional". Browsers reject bad certificates when the connection goes through, but if it times out, nothing happens. An attacker can simply block the OCSP server to bypass the revocation check. There's also the problem of privacy - you have to send the name of every website you visit to third party servers.

* In OCSP Stapling, the webserver acts like a proxy - it hosts a cached copy of the OCSP response for itself (it cannot be forged because it's signed by the CA) and sends it to clients in-band, via normal TLS channel. Because now the client no longer asks CA's OCSP servers for a response, but instead simply asks the webserver itself, it eliminates the problem of third-party OCSP servers, solves the reliability and privacy issues. However, there's nothing to prevent an attacker to run a server with a compromised certificate with OCSP Stapling turned off.

* In OCSP Must-Staple, you can get a certificate from a CA that says "you must use OCSP Stapling, otherwise this certificate is null and void." Hence, if a browser sees a certificate with "OCSP Must-Staple" enabled, it must see whether the webserver supports OCSP Stapling, and via OCSP Stapling, the certificate's validity will be determined. If OCSP Stapling is not supported by the webserver, the connection is rejected. Thus, an attacker who uses a compromised certificate has to either disable OCSP Stapling and be rejected, or to enable OCSP Stapling and gets caught. Finally the problem of reliable revocation is solved. But this is an optional feature and is only used by a tiny percentage of sysadmins. Also, it's only supported by webservers and browsers, other TLS-based applications like VPN, FTPS, SMTP, IMAP, XMPP, IRC servers/clients, etc, usually don't support OCSP Stapling at all.

Thus, it's often practically impossible to reliably revoke a certificate in SSL/TLS after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability, an unrevokable certificate that expires within 90 days is less dangerous than a zombie certificate that lasts two years.