Mobile client workarounds for ISRG issue

Issuance Tech
21

Stackoverflow Question and self-answer - https://stackoverflow.com/questions/64844311/certpathvalidatorexception-connecting-to-a-lets-encrypt-host-on-android-n-or-ea

2 Likes
22

I've documented a brief summary of adding ISRG roots using Network Security Configuration: https://www.danieldent.com/blog/android-apps-lets-encrypt-dst-root-expiry/

2 Likes
23

@DanielDent Nice! might be worth moving the "may only fully work with Android 7.0+" out of the footnotes since it gives a sizeable 7-12% of users, but doesn't solve for a lot of other app developers.

2 Likes
24

Thanks, all, for these helpful tips. @yschimke, I'm having trouble following your Android versions.

At the top of your Stackoverflow post you say "Android N or earlier fails". Android N is 7.0, API 24. My understanding is that API 25 (Android 7.1, 7.1.1, 7.1.2) may also fail because ISRG Root X1 shipped with Android starting with 7.1.1. This comes from https://letsencrypt.org/2020/11/06/own-two-feet.html which says "this includes versions of Android prior to 7.1.1." I would expect your post to say Android 7.1 or earlier fails. Or does OkHTTP do something to address API 24 and 25? I only have one device in that range and it does in fact happily accept the cert in Chrome and in my app. Perhaps the version when certs got bundled with Android varies by vendor.

If there is no special handling for API 24 and 25, then I think it would help to also explicitly point to the network-security-config approach.

2 Likes
25

There is a simple explanation, there was someone else in the room so I couldn't sing the alphabet song out loud to correctly order my versions. Good catch, thanks for correcting it.

I think this is the correct version of things.

Name Version number(s) API level ISRG Root X1 network-security-config OkHttp 3.12 Fix
No official codename 1 1
1.1 2
Cupcake 1.5 3
Donut 1.6 4
Eclair 2.0 – 2.1 5 – 7
Froyo 2.2 – 2.2.3 8
Gingerbread 2.3 – 2.3.7 9 – 10 X
Honeycomb 3.0 – 3.2.6 11 – 13 X
Ice Cream Sandwich 4.0 – 4.0.4 14 – 15 X
Jelly Bean 4.1 – 4.3.1 16 – 18 X
KitKat 4.4 – 4.4.4 19 – 20 X
Lollipop 5.0 – 5.1.1 21 – 22 X
Marshmallow 6.0 – 6.0.1 23 X
Nougat 7.0 – 7.1.2 24 – 25 7.1.1+ X X
Oreo 8.0 – 8.1 26 – 27 X X X
Pie 9 28 X X X
Android 10 10 29 X X X
Android 11 11 30 X X X
5 Likes
26

That's fantastic! Thanks! :smiley:

2 Likes
27

:smile: Google assembled its best minds to design the most confusing versioning systems possible.

Thanks for that helpful table and the update to your SO post! I still recommend pointing to the network-security-config docs for API 24-25 in your answer to make it 100% complete. :blush:

1 Like
28

I added a separate answer https://stackoverflow.com/questions/64844311/certpathvalidatorexception-connecting-to-a-lets-encrypt-host-on-android-m-or-ea/64887870

2 Likes
29

This looks like evidence that it's working for a real app already.

2 Likes
30

Wait, they really got rid of the dessert codenames :cupcake: :doughnut: :icecream: :chocolate_bar: :lollipop: after Android 9!? :cry:

Thanks for the research and the concise summary!

3 Likes
31

Putting this comment here because it's worth calling out without any applicable advice.

In the face of

  • Different JSSE providers (Android versions, or JDK)
  • potential cross signed certificates
  • different peer certificates served by the webserver

pinning seems really unpredictable. So I'd consider any of the advice above for OkHttp to be assuming that you aren't also trying to use certificate pinning. If you are, talk to your own sizable in-house security team and agree with them.

Some experimental results under a range of contrived conditions.

2 Likes
32

What about android apps using a WebView component? (A WebView usually uses the default system browser the phone is shipped with, and I'm not sure a workaround could be used for that)

Also, I guess mobile apps relying on Apache Cordova and similar systems could have problems with this change.

1 Like
33

I'm not an expert on webviews, I don't know definitive answer and I haven't tested. My incomplete understanding is that webviews would be broken still.

Some links I found on the topic which suggest there isn't a clean fix.

Some links for webviews for bookmarking, but advice is strongly not to do this.

How to use OkHttp for loading resources in WebView (DON'T DO IT)

https://gerrit.wikimedia.org/r/c/apps/android/wikipedia/+/343294/

1 Like
34

Any other suggestions for WebViews?

1 Like
35

For webviews one could override onReceivedSslError and then perform a manual chain validation upon SSL_UNTRUSTED error.
In this case root and intermediate certs need to be bundled with the APK.

You can check https://github.com/duckduckgo/Android/pull/1035

3 Likes
36

Nice PR. Is it worth putting this as a stackoverflow Q & A to get some attention in a probably more obvious forum?

2 Likes
37

This inflight PR from the duckduckgo repository looks great for the API cases https://github.com/duckduckgo/Android/pull/1037/files

2 Likes
38

Yes, I think it is a good idea. I can open a SO for it. Do we have already a SO for the other cases, we could also cross-reference them.

1 Like
39

Yep, someone added Volley and HttpsUrlConnection as well

But a separate Webview question seems appropriate.

1 Like
40

Added it here: https://stackoverflow.com/questions/65304273/handling-lets-encrypt-new-certificates-in-webview-for-android-m-and-older/65304274#65304274

Also completed your original one with solution for Glide

1 Like