Jon, > Using the .NET networking stack and using the > ServicePointManager.ServerCertificateValidationCallback callback allows me > to connect to a site which uses a self-signed certificate
This is not what I want to achieve. What am I trying to do here is, I believe, "officially" called Mutual SSL authentication. In case this kind of authentication is used, the SSL handshake consists of two additional steps - quoting from http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=%2Fcom.ibm.mq.csqzas.doc%2Fsy10660_.htm, that would be steps 5 and 6: 5. If the SSL server sent a "client certificate request", the SSL client sends a random byte string encrypted with the client's private key, together with the client's digital certificate, or a "no digital certificate alert". This alert is only a warning, but with some implementations the handshake fails if client authentication is mandatory. 6. The SSL server verifies the signature on the client certificate. This is what I am having problems with. I am sorry, but I don't see how your sample project would help me - I believe ServerCertificateValidationCallback fires for step 3 of SSL handshake (refering to the IBM document above). My problem has nothing to do with server-side certificiates. I am pretty sure you are already familiar with how the SSL handshake works :), I just want to be absolutely positive we are on the same page here. With that in mind, I'll try to rephrase the problem again. To complete the SSL handshake, it is necessary to encypt some random piece of data with client's private key. The private key used for the encryption is normally stored in X509Certificate2.PrivateKey property - when using such X509Certificate2 with HttpWebRequest, the SSL handshake completes successfully and everything is great. On Android, my app uses the KeyChain to get its hands on the certificate and private key. Now, to be able to use .NET HTTP stack and Mutual SSL authentication, I have to create an X509Certificate2 instance and set it up with a private key from the KeyChain. To do that, I have to convert that key to raw bytes, which is no longer possible with Android 4.1 (my original post). So as an alternative, I tried to use Android HTTP stack and hoped it will be successful since there is no private key converting involved. However, that failed, too (post #4). And now, I seem to be out of options :( > Unfortunately, I cannot use your code as-is, as it's missing crucial > contextual information, e.g. what is the value of `alias`, and what (if > any) device configuration do I need to do to make it work? The value of 'alias' depends on the exact client certificate being used. In my case, it is "client02", but I suppose that won't help you much :) It is not that simple to provide you with a complete sample - generally spekaing, to reproduce this, there needs to be a complete environment with HTTPS server requiring client certificates as a part of SSL handshake and any Android 4.1 device with the proper client certificate installed. If you think it would help to resolve this, I can prepare such an environment relatively quickly. -- View this message in context: http://mono-for-android.1047100.n5.nabble.com/KeyChain-API-on-Android-4-1-and-client-certificate-authentication-tp5712844p5712866.html Sent from the Mono for Android mailing list archive at Nabble.com. _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
