Oops. 10.x.x.x is a private range. No wonder it didn't work. Do you have a test server that's publicly accessible?
Alex On Mon, Jul 7, 2014 at 2:47 PM, Alex Klyubin <[email protected]> wrote: > Does your server request a client cert for all incoming connections or > only for those on which SNI is set correctly? Also, do you have a > publicly accessible server that I could connect to in order to > reproduce? I tried 10.22.1.100:443 but the TCP connection timed out. > > Regards, > Alex > > On Thu, Jul 3, 2014 at 8:43 AM, Derek Cole <[email protected]> wrote: >> Just to add another data point, I also tried to make a "Trust all certs" >> TrustManager like so: >> >> TrustManager[] trustAllCerts = new TrustManager[] { >> new X509TrustManager() { >> public java.security.cert.X509Certificate[] getAcceptedIssuers() { >> return null; >> } >> public void checkClientTrusted( >> java.security.cert.X509Certificate[] certs, String authType) { >> } >> public void checkServerTrusted( >> java.security.cert.X509Certificate[] certs, String authType) { >> } >> } >> }; >> >> Even using this, I do not see any calls into my KeyManager. However, if I >> changed my SocketFactory to use a SSLContext, Like so - >> >> >> SSLContext context = SSLContext.getInstance("TLS"); >> >> final X509KeyManager origKm = (X509KeyManager) >> keyManagerFactory.getKeyManagers()[0]; >> X509KeyManager km = new ACx509KeyManager(origKm); >> >> context.init(new KeyManager[]{km}, trustAllCerts, new >> SecureRandom()); >> sslSocketFactory = (SSLSocketFactory) >> context.getSocketFactory(); >> >> Then I do see the calls to the ACx509KeyManager. I'm not sure what the >> difference is, but I don't think I can use the SSLContext and still do SNI >> can I? >> >> Thanks, >> >> Derek >> >> >> On Thu, Jul 3, 2014 at 11:03 AM, Derek Cole <[email protected]> wrote: >>> >>> Hello, >>> >>> So I have completed having a wrapper for both the KeyManager and >>> TrustManager. For the trust manager, I put in some Log.d statements on the >>> checkServerTrusted() method, and I see the following - the first ine is the >>> authType (RSA). The next two lines are where I looped over the >>> X509Certificate[] that is the chain arg in that method. >>> >>> 07-03 10:52:50.752 20655-20853/de.blinkt.openvpn D/ACx509TrustManager﹕ >>> checkServerTrusted : authTypeRSA >>> 07-03 10:53:17.748 20655-20853/de.blinkt.openvpn D/ACx509TrustManager﹕ >>> CN=mydomain.local,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU >>> 07-03 10:53:25.816 20655-20853/de.blinkt.openvpn D/ACx509TrustManager﹕ >>> 1.2.840.113549.1.9.1=#1607756e6b6e6f776e,CN=Falcon Root >>> CA,O=Falcon,L=Alexandria,ST=Virginia,C=US >>> >>> mydomain.local is definitely the certificate I am sending from my stunnel >>> server. I am not really sure what that third line is saying - it looks like >>> the right info from my cert authority's cert. (just made up values) >>> >>> How do I know whether the server's cert actually got trusted or not? >>> >>> >>> On Wed, Jul 2, 2014 at 6:41 PM, Brian Carlstrom <[email protected]> wrote: >>>> >>>> For the client cert part, I would add a wrapper around the >>>> X509KeyManager/X509ExtendedKeyManager instance to see if the SSLSocket >>>> is calling you to ask for client certificate during handshake. Looks >>>> like someone on stack overflow suggested this. I'd also make sure with >>>> wireshark or tcpdump that the server is requesting a client >>>> certificate with a CertificateRequest message. >>>> >>>> But I'm guessing it is not sending the client cert because the client >>>> devices it doesn't trust the server. so I'd add a wrapper on the >>>> X509TrustManager to log as well to see the chain that the SSLSocket is >>>> trying to validate. I assume you aren't using an intermediate CA? >>>> again I'd look with wireshark to see what certs the server is sending >>>> to the client. >>>> >>>> -bri >>>> >>>> On Wed, Jul 2, 2014 at 3:16 PM, Derek Cole <[email protected]> wrote: >>>> > Hello, >>>> > >>>> > I hate to cross-post, but I have posted a question here: >>>> > >>>> > http://stackoverflow.com/questions/24518570/client-certificate-not-sent-from-android-to-ssl-server >>>> > >>>> > Basically, I am trying to use my own CA, and my own cert signed by >>>> > that CA >>>> > to connect to a server that has a cert signed by that same CA. I am >>>> > unable >>>> > to get my android client to send a cert to the server. What am I doing >>>> > wrong? >>>> > >>>> > I am using a SSL utility class to help manage the keystores. >>>> > >>>> > https://github.com/ubergeek42/weechat-android/blob/master/weechat-android/src/main/java/com/ubergeek42/WeechatAndroid/service/SSLHandler.java >>>> > >>>> > My basic idea is that I am loading my CA's cert into a keystore, and >>>> > then >>>> > using that keystore to initialize a TrustManagerFactory. >>>> > >>>> > I then make another keystore, load in my client-cert, and then >>>> > initialize a >>>> > KeyManagerFactory with that store. >>>> > >>>> > Finally, I create the socket factory with those trust and key managers: >>>> > >>>> > sslCertSocketFactory = (SSLCertificateSocketFactory) >>>> > SSLCertificateSocketFactory.getDefault(100000); >>>> > sslCertSocketFactory.setKeyManagers(kmf.getKeyManagers()); >>>> > >>>> > sslCertSocketFactory.setTrustManagers(tmf.getTrustManagers()); >>>> > >>>> > >>>> > Now, whenever I use that factory to creatSocket(), I get a >>>> > SSLHandshakeException on the android client, and the server simply >>>> > reports >>>> > the peer did not send a cert. >>>> > >>>> > The whole point was to be able to use >>>> > sslCertSocketFactory.setHostname(socket, "mysniname.local"); >>>> > >>>> > To set the SNI servername so that my server knows what to do with the >>>> > incoming connection. >>>> > >>>> > I have been stuck for days, any help is appreciated. If it is possible >>>> > to >>>> > produce my end result (the SNI functionality) with something else >>>> > entirely, >>>> > I am all ears. >>>> > >>>> > Thanks! >>>> > >>>> > -Derek >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> > Groups >>>> > "Android Security Discussions" group. >>>> > To unsubscribe from this group and stop receiving emails from it, send >>>> > an >>>> > email to [email protected]. >>>> > To post to this group, send email to >>>> > [email protected]. >>>> > Visit this group at >>>> > http://groups.google.com/group/android-security-discuss. >>>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Android Security Discussions" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to >> [email protected]. >> Visit this group at http://groups.google.com/group/android-security-discuss. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/d/optout.
