Let’s Encrypt Will Stop Working For Older Android Devices

Let’s Encrypt was founded in 2012, going public in 2014, with the aim to improve security on the web. The goal was to be achieved by providing free, automated access to SSL and TLS certificates that would allow websites to make the switch over to HTTPS without having to spend any money.

Hundreds of millions of sites rely on Let’s Encrypt for their HTTPS certificate needs. HTTPS security helps protect sites and users, and makes it harder for malicious actors to steal private information.

The project has just announced that, come September 1, 2021, some older software will stop trusting their certificates. Let’s look at why this has come to pass, and what it means going forward.

Certificates Expire

When Let’s Encrypt first went public in early 2016, they issued their own root certificate, by the name ISRG Root X1. However, it takes time for companies to include updated root certificates in their software, so until recently, all Let’s Encrypt certificates were cross-signed by an IdenTrust certificate, DST Root X3. This certificate had been around much longer, and was already supported by the vast majority of OSes and browsers in regular use. This allowed Let’s Encrypt to hit the ground running while they waited for the majority of software to support their own root certificate.

The problem looming on the horizon is the expiration of DST Root X3, on September 1, 2021. Of course, for those running up-to-date operating systems and browsers, there’s no major issue. But for those on platforms that haven’t been updated since 2016 or so, and don’t support the ISRG Root X1 certificate, things will break. This affects any secure communication that uses their certificates, whether it be browsing websites with HTTPS enabled or making connections over SSL or SFTP.

The company notes that perhaps the biggest area of concern is the Android handset market. As most telecommunications networks customise Android software, along with the handset manufacturer themselves, it takes coordination between many organisations to put out an OS update for an Android phone. There’s also little financial incentive for companies to support phones that have already been sold. Thus, many users find themselves locked out from OS updates entirely as networks or manufacturers simply neglect to do the work.

Data on the Android installed base, as of September 2020.

Android users on versions older than 7.1.1 are the ones who will face issues when DST Root X3 expires on September 1 next year. Based on recent statistics, these users make up roughly a third of the Android userbase – a significant number. With a conservative estimate pegging Android users as a whole making up approximately 80% of the total smartphone installed base, and around 3 billion smartphone users worldwide, back of the envelope calculations show us that leaves around 750 million users that could have issues in the coming year.

Of course, workarounds are possible. While the Android OS, and presumably web browser, are long out of date, there’s nothing stopping users installing newer software that supports the ISRG Root X1 certificate. Firefox is available as a browser on the platform, and packs in its own list of trusted root certificates, so is a useful workaround for day to day web use. For developers, it’s possible to include ISRG Root X1 as a trusted certificate within an individual app, and discussions are ongoing among those taking to this route. After all, adding an new trusted certificate is just putting a file in a directory, but you need root permissions to do so, which on locked Android phones means a jailbreak.

Let’s Encrypt could also seek a cross-signature from another Certificate Authority, similar to when they started out. However, Certificate Authorities take on some responsibility for the certificates they sign, and it’s unlikely that another CA would wish to shoulder that burden for Let’s Encrypt. Particularly, as the entity is a non-profit, there is little money to be made. As a major pillar in the Internet’s shift towards HTTPS encryption as the norm, Let’s Encrypt consider it important that the project stand on its own, rather than relying on other for-profit organisations. Given that their root certificate is now widely recognised, outside these edge cases from 2016 and earlier, that seems like a sound decision.

With security on the Internet now more important than ever, this is a problem that isn’t going away. In order to play nice with all the other computers on the global network, regular updates are simply the cost of doing business. The benefit of having an open certificate provider like Let’s Encrypt around is that their transparency as to the issues and clear communication gives web hosts, developers, and end users more time to deal with the coming changes.


20 thoughts on “Let’s Encrypt Will Stop Working For Older Android Devices

    1. If I understand right, the problem is the built-in Android browsers that won’t be getting updates. If you use e.g. Firefox or Chrome on your phone _or_ laptop, and keep it updated, I think it should last forever.

    2. Just install the new root cert manually. Like you’ve had to do for the past year for all other certificate authorities that expired.

      Heads up for Win 7, you’ve also had all UTN, Deutsche Telecom, GTE, and Equifax issued certificates stop working for the exact same reason.
      You’ll have DTS and GlobalSign expire next year, that last one will cause a few million certificates to stop working for you.

      You’ll need to manually update them all going forward (Well, maybe skip Equifax)

  1. Just checked, I have to bin my feature phone because it’s too old (Android 7.0), even though I only got it 2 years ago. What also sucks is that my wireless carrier Verizon has the capability to update the device, as they did with a security patch a couple months ago, but likely won’t release an android update for my device. Also their security patch broke the search bar in the settings app, which frankly I’m puzzled by. I’d try rooting, but again: feature phone.

    1. You also could install a browser that has its own certificate trust store separate from your Android system’s root store. That way you’d have the ability to browse all the sites, maybe just not very conveniently.

      It all depends on how you want to spend your money.

  2. “Let’s Encrypt was founded in 2012, going public in 2014,”
    “When Let’s Encrypt first went public in early 2016”
    It looks like they first went public 2 years after going public.

  3. Android actually allows the user to install their own certificates. System settings –> security –> encryption –> install certificate. The setting may have moved around over the years, but it’s there.

  4. I really hate the way PKI works today. It completely locks out any kind of home server for most people because you need to pay for a domain, it makes it impossible to use advanced HTML features on decentralized networks without a hassle, and devices don’t support it well.

    There should always be a settings menu on consume devices to easily add a new root certificate. You should be able to embed public keys directly in URLs as base64, for all the applications that don’t need to be human-readable, like IoT devices with QR codes for setup.

    Keep PKI for your bank and Facebook (Who probably aren’t using let’s encrypt anyway), and let other things use alternatives. If you’re the type to enter your credit card info at xuebifuwbjidbsjwneisnsiwnd., you’re going to do the same at TotallyHonestNotAScamBanking.com anyway.

    1. What?

      Does dyndns still have a free level? I used to use a free domain name through them. Before that I used ods.com or ods.net or something like that which is gone now. At some point I paid a one time fee for some upgrade to my dyndns.org account and am grandfathered into that now.

      Anyway, if you aren’t grandfathered into something just google “free dynamic dns” https://lmgtfy.app/?q=free+dynamic+dns It looks like there are many. Combine that with Let’s Encrypt and you are good to go.. so long as you don’t want to use any old devices apparently.

      Really I wish I could just click those “accept this self-signed certificate” and “remember always” buttons and have my browser actually do what I am telling it to do. But you know.. those security types they hate functionality and they hate people that host their own stuff and the business types are perfectly happy to keep taking our money. But at least there are the options I mentioned above to get around all that.

    2. I completely agree that browsers forcing SSL on LAN and older devices is the wrong approach. I find it just as wrong as Mozilla’s approach in Firefox.
      Who to trust and not trust is my call, not theirs. My trust stems from actual trust, not who pays a yearly fee vs who doesn’t.

      I ended up going the route of running my own CA, which is fine for everything except Firefox that refuses to let me trust my own CA. Mozilla needs to be wiped off the Internet for crap like that.

      The “fix” I made for LAN devices is a huge hack. but works great. I have a non-obvious sub-domain on my Internet domain that is completely internal, DNS servers too.
      On the public internet, there is a wildcard DNS entry in that subdomain that directs to a single public web server I run. It has my LetsEncrypt fingerprint in it, and will validate any ACME requests to “:*” with the proper reply.

      This way any unreachable LAN device can make ACME requests for certs and be approved, getting legit certs each on their own key.

      The worst case risk is someone else could potentially have certs issued to a name in my sub-domain, to put on a server that could never be reached. and I’m OK with this.

        1. Nothing unlikely about it.
          When I install my CA root cert into Firefox, it will be deleted on the next browser update.
          This is well defined behavior: https://wiki.mozilla.org/CA/FAQ#What_is_the_Mozilla_Root_Store_Policy.3F

          Likewise, when I disable a CA cert in firefox because I do not trust it, such as CNNIC, upon the next browser update Mozilla will reenable it again, because Mozilla is paid to include it.
          This is also intentional behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=542689

          Like I said, to me, trust means trust. To Mozilla, trust means they get paid.
          I don’t pay them and so I can’t trust myself. The govt. of China pays them so I must trust them.

          I don’t subscribe to this redefinition of the word “trust”, and even if I did, Mozilla doesn’t pay me so by their own definition I can’t trust Mozilla.

          1. From your link:
            “Deleting a root certificate that is in the default root store is equivalent to turning off all of the trust bits for that root. Therefore, even though the root certificate will re-appear in the Certificate Manager, it will be treated as though you changed the trust bits of that root certificate to turn them all off.

            Important: This change will have a permanent affect, such that the trust bits for the root certificate can only be changed again by you. This change will not be affected by upgrading to newer versions of Mozilla software. It is strongly recommended that you note which root certificate you modify, so that you can turn the trust bits back on if the change negatively impacts your browsing experience.”

        2. I’d give links to prove it, but it seems the comment system disappears my posts containing links.
          Firefox updates revert changes to their certificate store, deleting mine, and putting back ones I delete. It’s documented behavior.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.