There certainly were no exceptions. I guess I might have missed a warning but I don't think so.
as far as trusting the certificate we have an out of band method for verifying the certificate when you first create the keypair, then after that the server can check if the cert is the one it expects for that user. We do not care about any information contained in the cert just that we are talking to the same phone (keypair) On Jan 10, 1:36 am, Nikolay Elenkov <[email protected]> wrote: > On Tue, Jan 10, 2012 at 6:14 PM, Carl Minden <[email protected]> wrote: > > Hmm, if there was a parse error I wonder why no exception was thrown, > > as far as I can tell it just silently failed and didn't send the cert > > to the server. > > Because the framework code swallowed it? Did you see anything suspicious > in logcat (warnings, etc.)? > > > > > The reason I am not using the openssl tool is because I am creating > > the certificate on the phone using an RSA keypair generated at > > runtime. I know it probably sounds like i'm doing something wrong/ > > stupid :), but without getting into the details of my system the only > > thing I need this cert for is to use the keypair to perform SSL client > > auth and it really doesn't matter if it is signed. > > I see. Probably easier to do in Java (using Bouncy Castle APIs) though. > Still, client authentication should involve the server checking if it trusts > the client certificate (even if it is self-signed), and it should verify that > it's not been modified. How do you verify it's not modified if it's not > signed? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
