Finally! Mylyn is working in conjunction with encrypted client certificates. I started to think that this was impossible, as the server admins also have been fighting with client certificates in Java. But during my search on the Internet, I came across this page, which seemed to imply that the Java browser plugin supported PKCS12 keystores:
Once you have the plugin control panel open, go to the Advanced tab. At the bottom of the pane is a window for entering run-time parameters for the plugin. Enter the following text into the run-time parameters window.
-Djavax.net.ssl.keyStore=path to your .pfx file -Djavax.net.ssl.keyStorePassword=password to your .pfx file -Djavax.net.ssl.keyStoreType=PKCS12
Of course, the standard keytool documentation doesn’t give any mention of this and thus you are led to believe that you cannot use a standard PKCS12 certificate as the keystore.
Which, in the end, is exactly what I did. I added the following lines to eclipse.ini:
-Djavax.net.ssl.keyStore=d:\Java\.P12
-Djavax.net.ssl.keyStorePassword=
-Djavax.net.ssl.keyStoreType=PKCS12
And it works:
Which means that I can finally put this quest to rest. Everything works as advertised in Mylyn & Eclipse. The only downside that I found so far has been that I have to use the Trac-Web interface of Mylyn instead of the XML-RPC interface (which is not nor will be supported on our server).
As you may have read on this blog before, I’ve been trying to marry Mylyn to the company provided Trac server. This integration has been unsuccessful as to now, as I receive a handshake_failure every time I try to validate the settings:
I’ve decided to try and get to the bottom of this. I’ve fired up Wireshark and made network traces of the connection. So far, I’ve found one interesting item: it seems that the certificate is not being sent at all! That is: if my understanding of the TLS RFC is correct. The RFC states:
7.4.6. Client certificate
When this message will be sent:
This is the first message the client can send after receiving a
server hello done message. This message is only sent if the
server requests a certificate. If no suitable certificate is
available, the client should send a certificate message
containing no certificates. If client authentication is required
by the server for the handshake to continue, it may respond with
a fatal handshake failure alert. Client certificates are sent
using the Certificate structure defined in Section 7.4.2.
And this is what I seen in Wireshark:
I get the feeling that the problem may be centered around the fact that my client certificate is protected with a password. I’m gonna get to the bottom of this…
It seems that the intrepid hackers at xda-developers are at it again. They’ve been working away on porting Google Android to run on many different types of HTC kit. At the moment, ports are underway for the HTC Vogue (a Touch for CDMA-based networks), HTC Polaris and HTC Tytn II. As I’m using an HTC Touch ( the one with the measly 64Mb of RAM) I left in the cold for the moment…
Which prompted me to see if I can run Android on my phone as well. I’ll try and chronicle my efforts here.
