New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSLSocketFactory with Client Certificate works fine with okhttp2 but not with okhttp3 #2786
Comments
How does it fail? It's working for other developers! |
Thanks for response, The problem I am actually facing is: I have two keystores to manage, the first resembles to yours I refere to it in my code with : TrustStore it has a Certificates Authority . the second is a appKeyStore has a client certificate and a password. But in your example you have one and only one keystore (TrustKeystore). With okhttp2 I initialezed keyManagerFactory with appKeyStore as follow:
and for the trustStore I used :
But this does not work with okhttp3: While following your solution I did not use the trustStore, I initilized the keyManagerFactory and the TrustManagerFactory with the appKeyStore. As result I get :
I adapted your solution to my situation, I initialised the TrustManagerFactory with TrustStore and as result I get :
how can I use the TrustStore with okhttp3? Thanks in advance |
The trust store you pass to OkHttp should be the one you're using to validate the server's certificates. Typically these are from a certificate authority. |
Yes, the trust store is from the CA and that work fine with okhttp2 and HttpURLConnection,
Do you have any idea of how i can create sslSolcketFactory and x509TrustManager for okhttp3 as from createSslSocketFactory( ) method ? Thanks in advance |
If I understand correctly, its an issue that you have two keystore files and the API doesn't make that possible.
If this is the case, I've done something similar with multiple trust stores. See But it is very possible I'm misunderstanding. |
@yschimke, In fact I have two kestores :
The second keyStore is the trustStore that contains Certificates Authourity, and I initialize my TrustManagerFactory with it:
To adapt my code to okhttp3 I used @swankjesse sample, but the diffrence remains in the fact that it doesn't handle a keyStore, for KeyManagerFactory, with Client Certificate. It uses only Certificates Authority in a trustKeyStore. As a reminder my public SSLSocketFactory createSslSocketFactory() {..} works very fine with okhttp2 and HttpURLConnection. |
I’m not quite sure what we could be doing differently on this. The big change in 3.x is that we accept a separate X509TrustManager but it’s only used for certificate pinning. At the moment we don’t have any tests that do HTTPS with client certificates. Would you be interested in contributing one? |
My reading is that BasicCertificateChainCleaner also filters certificates if it can't find a trusted root CA in the trust manager. i.e. it effects things even without certificate pinning. |
I would love to contribute in solving the problem. |
I created a test case for the non-android case showing client auth working #2804 You could use this to make a similar test for Android. |
Just for shits and giggles, does your existing code still work with 2.7.4? |
@yschimke yes it does work fine with 2.7.4. |
https://github.com/square/okhttp/wiki/HTTPS#customizing-trusted-certificates |
No action to take on this. |
@mboukadir Did you ever find a proper solution to this? I am facing the same problem with a client certificate. If I use the client certificate for the trusManager, the app complains about "missing trust anchor", and if I use the server certificate for the trusManager, the "connection is reset by the peer". |
@bjornson any solutions? |
Here's how I created the SSLSocketFactory that works fine with okhttp2.x but not with okhttp3:
With okhttp3 i have tried this, as @swankjesse did in : exemple CutomTust [https://github.com/square/okhttp/blob/master/samples/guide/src/main/java/okhttp3/recipes/CustomTrust.java], but in my case I have to use TrustStore :
Here is where I manage the TRUSTSTORE
Thanks in advance
The text was updated successfully, but these errors were encountered: