And onReceivedSslError would cover the self-signed scenario, but it wouldn't cover the real pinning scenario with a properly signed cert, because it gets invoked only on a handshake failure, not a handshake success.
On Jan 14, 2014, at 11:38 AM, Marcel Kinard <cmarc...@gmail.com> wrote: > I've played with that recently, and it may do most of what you want. > > The method CordovaWebViewClient.onReceivedSslError does get called when > attempting an SSL handshake with a server that has a self-signed cert. I > tested this using <a href> and window.open(_self). > > When setting the app to debuggable=true in AndroidManifest.xml, the > onReceivedSslError() method will treat this as a special case, and basically > ignore the SSL error by always calling SslErrorHandler.proceed(). Once > proceed() has been called, subsequent SSL connections to that server will not > result in onReceivedSslError() getting called - once that self-signed cert > has been accepted, subsequent requests are considered accepted also. This > "acceptance" is persistent only for the duration of a single application > execution - if the application is restarted, it forgets the acceptance. > According to the docs, WebView.clearSslPreferences() might reset that. > > When using debuggable=false, it takes a different path in > onReceivedSslError() and it doesn't eat the error, and the connection fails. > I think at this point what you'd want to do is inspect the cert to see if it > matches what you want, and then call proceed() if it is good. However, I > think the last sticking point (from what I see in the javadocs) is that > although you are handed an SslCertificate object in onReceivedSslError, the > methods on SslCertificate will get you only the human-readable info (self DN, > issuer DN, valid date) and not the actual public key. So all you can check is > the DN, which I don't think is good enough. I don't see a way to work around > that by getting the raw pem or similar. > > On Jan 14, 2014, at 10:42 AM, Andrew Grieve <agri...@chromium.org> wrote: > >> Actually, looking again, there's a custom API just for SSL certs that >> will provide you the cert to check: onReceivedSslError(). >
