In January 2021 all devices with Android prior to 7.1.1 will not be able to connect to HTTPS servers using Let's Encrypt certificate (Let's Encrypt blog post explaining the details)

Is there any workaround that's system-wide (i.e. all apps, not just a single app, like using Firefox) for the SSL certificate expiration on Jan 11th 2021? Assume that one has root access to their device, and that upgrading to a newer device is not an option.


1 Answer 1


Update 2024-04-10

Let's Encrypt cross signing is still valid, but since Feb 8th 2024 the default new server certificate doesn't seem to make use of the cross signing capability:


On Thursday, Feb 8th, 2024, we stopped providing the cross-sign by default in requests made to our /acme/certificate API endpoint. For most Subscribers, this means that your ACME client will configure a chain which terminates at ISRG Root X1, and your webserver will begin providing this shorter chain in all TLS handshakes. The longer chain, terminating at the soon-to-expire cross-sign, will still be available as an alternate chain which you can configure your client to request.

Update 2023-07-11

By the current schedule, Let's Encrypt cross signing will end on September the 30th 2024. After this date Android 7.1 stock devices will become more or less useless for Internet surfing as all Let's encrypt based certificates will be considered untrusted and the connection will not be established.

Update 2020-12-21

Let's Encrypt has delayed the new root CA certificate for 3 years:

We’re happy to announce that we have developed a way for older Android devices to retain their ability to visit sites that use Let’s Encrypt certificates after our cross-signed intermediates expire. We are no longer planning any changes in January that may cause compatibility issues for Let’s Encrypt subscribers.

A recurring theme in our posts about our upcoming chain switch has been our concern over the effects on users of Android operating systems prior to 7.1.1, whose devices don’t trust our ISRG Root X1. Thanks to some innovative thinking from our community and our wonderful partners at IdenTrust, we now have a solution that allows us to maintain wide compatibility. Critical to our mission as a nonprofit is to help create a more secure and privacy-respecting Web for as many people as possible. This work brings us closer to that goal.

IdenTrust has agreed to issue a 3-year cross-sign for our ISRG Root X1 from their DST Root CA X3. The new cross-sign will be somewhat novel because it extends beyond the expiration of DST Root CA X3. This solution works because Android intentionally does not enforce the expiration dates of certificates used as trust anchors. ISRG and IdenTrust reached out to our auditors and root programs to review this plan and ensure there weren’t any compliance concerns.

As such, we will be able to provide subscribers with a chain which contains both ISRG Root X1 and DST Root CA X3, ensuring uninterrupted service to all users and avoiding the potential breakage we have been concerned about.

We will not be performing our previously-planned chain switch on January 11th, 2021. Instead, we will be switching to provide this new chain by default in late January or early February. The transition should have no impact on Let’s Encrypt subscribers, much like our switch to our R3 intermediate earlier this month.

Extending Android Device Compatibility for Let's Encrypt Certificates

Installing new Let's Encrypt root CA certificates

If your device is running Android 5 and before or is rooted you can install the missing root CA certificates yourself. As far as I know the following two certificates have to be added:

On Android 5 and before you can simply install them as "user certificate". Note that this automatically forces you to use a lock screen with pattern/PIN or password lock.

Older rooted devices

On older Android devices that are rooted you can add the new Let's encrypt root CA certificates to the system certificate store /system/etc/security/cacerts.bks.

To do so download this file to a computer and use KeyStore Explorer to add the Let's encrypt root CA certificate files and save it. Then write back the cacerts.bks to your Android device.

Newer rooted devices

On newer, rooted devices the easiest way is if the device is rooted via Magisk, then you can install the two certificates as user certificates and then move them to the system store using the Magisk Module Move Certificates.

If Magisk and the mentioned module is not available you can still install the certificates as user certificates and move them manually to the system store.

The installation process is very similar as shown in the installation tutorial for the mitmproxy root-ca certificate.

The followings section shows the certificate hash values for the Let's encrypt certificates:

openssl x509 -inform PEM -subject_hash_old -in isrgrootx1.pem | head -1

openssl x509 -inform PEM -subject_hash_old -in isrg-root-x2.pem | head -1

Also make sure that the copied certificate file has the correct permissions:

chmod 644 /system/etc/security/cacerts/6187b673.0
chmod 644 /system/etc/security/cacerts/8794b4e3.0

Once you have installed the certificates you should be able to browse (without a security warning) to the following location: https://valid-isrgrootx1.letsencrypt.org/

  • 1
    In my case (android.stackexchange.com/q/242440/196632) I've got the ISRG Root X1 automatically in user installed certificates, without any action from me. It is as if it has self-installed itself. How was it possible?
    – Bento
    Commented Oct 30, 2021 at 9:44
  • Are there any further updates? Any way to update certificates on non-rooted older, but not really old, devices (e.g. after Android 5, but before Android 8?)? Commented Apr 10 at 6:16
  • @EndAnti-SemiticHate Sorry but on those Android versions there is simply no way to install a trusted root CA as user that is in the end trusted by all apps. The only way is a rooted device.
    – Robert
    Commented Apr 10 at 6:59
  • @Robert What about using a tool like AdGuard that can process all HTTPS traffic? IIRC, it can even disable OCSP checks. Now, of course, that would come with its own big set of risks, so such an action should not be taken without understanding those risks. Commented Apr 10 at 7:13
  • @EndAnti-SemiticHate AdGuard has the same problem: adguard.com/kb/de/adguard-for-android/solving-problems/…
    – Robert
    Commented Apr 10 at 7:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .