Mobile client workarounds for ISRG issue

: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

I added a separate answer


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


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!


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.


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

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)

1 Like

Any other suggestions for WebViews?

1 Like

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


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


This inflight PR from the duckduckgo repository looks great for the API cases


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

Yep, someone added Volley and HttpsUrlConnection as well

But a separate Webview question seems appropriate.

1 Like

Added it here:

Also completed your original one with solution for Glide

1 Like

6 posts were split to a new topic: is serving the wrong intermediate

@jsha Is this still the plan of attack for App Developers post Jan 11th? The blog suggests so

But I'm suspecting a lot of confused developers anyway, is there a more beautiful solution in the works, or people should ship a fix in their App with a new CA cert added to older Android clients?



@lestaff On the post the "If You Are an App Developer" should probably be marked as out of date also.

A post was split to a new topic: Questions re: Extending Android Device Compatibility

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.