Hi there,
I’m migrating my ionic3 + Cordova app to ionic5 + Capacitor and encountering a known and fixable issue on Cordova Android that I have to figure out with Capacitor.
Something in my https credentials fails the android chrome requests (iOS and chrome browser work fine btw). I have not been able to dig out the error from the remote console.
Here is how I was able to previously fix this https credentials fail with ionic3 & Cordova
Edit
platforms/android/CordovaLib/src/org/apache/cordova/engine/SystemWebViewClient.java
ll 237
add comment and code
// super.onReceivedSslError(view, handler, error);
// add code
handler.proceed();
return;
But now it fails with ionic5 and Capacitor. Any ideas how to fix this?
While you wait for better answers, I’m going to suggest fixing this underlying issue instead of trying to figure out how best to nerf SSL error handling. The most typical cause is failure to include all necessary intermediate certificates in your chain. Check the documentation for whatever certificate provider you’re using.
I know this would come 
yet, I would like to move forward on both ends, fix the cert and push testing on Android further at the same time. Also, I wonder why this is platform specific when iOS can handle the cert well…
Apologies if this is all old hat to you, but everything relies on a “chain of trust” model. Each browser is seeded with a bunch of certificates that it trusts, and in order for one to be considered valid, it has to be signed by one of those.
In order to limit the possibility of a CA root cert being compromised, they are typically not used to sign end-user certs directly. Instead, the CA root is used to sign a second-level cert that is then in turn used to sign the certs you install on your servers. What is likely missing here is the intermediate certificate showing that CA root has signed CA-2. It is possible that iOS is trusting CA-2 implicitly, whereas Android is only trusting CA root but not CA-2. If you present the intermediate cert showing CA root trusting CA-2.
Again, exactly how to do this depends on your cert provider - I use LetsEncrypt, which gives me cert.pem, chain.pem and fullchain.pem. If I just include cert.pem, I will see the symptoms you describe. fullchain.pem combines the contents of cert.pem and chain.pem, and if I present that, everything works on all devices (well, at least until next October when DST X3 expires and old Android devices don’t trust LetsEncrypt’s ISRG Root X1, but that’s another topic).
Thanks for the last paragraph. Yes, I remember using a cert validation site and it showed something similar for my certs. I was able to navigate around these issues thus far, lazy me, haha… I will check LetsEncrypt . Thus far I was buying the cert from my provider and getting it to work into apache required some tweaking so I do not really want to mess with that stuff and break my currently working system…
It LetsEncrypt is free, I will move for sure when my current SSL cert runs out.