Stackoverflow Question and self-answer - https://stackoverflow.com/questions/64844311/certpathvalidatorexception-connecting-to-a-lets-encrypt-host-on-android-n-or-ea
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/
@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.
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
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|
|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|
That's fantastic! Thanks!
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.
This looks like evidence that it's working for a real app already.
Wait, they really got rid of the dessert codenames after Android 9!?
Thanks for the research and the concise summary!
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.