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…
As I already listed in the first post of this duet, I want to integrate my Eclipse installation with a 3rd-party managed configuration management environment. The first part of this post dealt with the integration of subversion, but now I want to integrate Mylyn with the Trac-environment that is part of the CMaaS providers offering.
This all starts with entering a new task repository in the “SVN Repository Exploring” perspective:
I selected the Trac repository type and clicked Next:
However, clicking ‘Validate Settings’ yields an error:
Uhoh…. The Mylyn FAQ indicates that this is caused by a missing certificate in the Eclipse keystore. It suggests executing the following command on a commandline:
keytool -import -keystore /path/to/.eclipsekeystore -file /tmp/certificate.pem
This would import the certificate into the keystore. Unfortunately, my certificate is in PKCS#12 format and not in PEM format which is required by the Java JDK keytool. Thus, keytool complains with an error: “keytool error: java.lang.Exception: Input not an X.509 certificate“.
We will need a way to convert the PKCS#12 certificate into a PEM certificate. This is best done using OpenSSL. A download for Windows XP can be found here. After downloading and installing OpenSSL, I executed the following commands on the commandline:
openssl pkcs12 -in cert.P12 -out userkey.pem -nocerts
Enter Import Password:
MAC verified OK
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
openssl pkcs12 -in cert.P12 -out usercert.pem -nokeys -clcerts
Enter Import Password:
MAC verified OK
Now we have an almost usable certificate and a separate key. The openssl command includes a pre-amble in the certificate that keytools will complain about. Open userkey.pem in an editor and remove everything above the “—–BEGIN CERTIFICATE—–” line. After re-running keytool, the following output appeared:
keytool -import -keystore <path_to_eclipse_keystore>\.eclipsekeystore -file usercert.pem
Enter keystore password:
Re-enter new password:
< skipped output to protect the innocent >
Trust this certificate? [no]: yes
Certificate was added to keystore
Now the keystore is created and we can add it to eclipse by including the following lines in eclipse.ini:
-Djavax.net.ssl.keyStore=\path\to\.eclipsekeystore
-Djavax.net.ssl.keyStorePassword=123456
But what do you know… It still doesn’t work and the error shown below presents itself…
I found a bug in the Eclipse bugzilla that seems to refer to the exact same problem, therefore I think that this little quest is halted till this issue is solved. I’ll post updates when there are new developments.
OK, so here’s the deal: the company I work for uses a ConfigurationManagement-as-a-Service provider to handle configuration management for all internal projects. The provider itself is actually a subsidiary of the company but in the end this doesn’t matter much. For CM they use Trac and Subversion. Which is great. As a proper service provider, all CM configurations for customers are highly secured which is achieved in part by the use of client-certificates for both SVN and Trac. Getting Eclipse integrated with services listed as such was not as easy as it seemed. I’ve split my efforts into two posts: this one deals with subversion whereas the next one will deal with Trac.
First, the setup that I tried to make work:
- Eclipse 3.3.1 (Europa release)
- Mylyn 3.3.1 (Europa release)
- Trac 0.10.3
- Subversion (version unknown)
Everything will be running under Windows XP SP2.
First: Subversion
Integrating Subversion was supposedly as easy as installing Subclipse. This is done via a an update site, the installation instructions can be found here. After this, you can switch to the SVN Repository Exploring perspective. There I clicked ‘Add SVN Repository’ and filled in the URL. This is where the problems start. Subclipse (or at least the libraries it uses to handle SVN) does not ask for a client-certificate by default and connection to the repository fails. A little googling pointed me to the following page that stated that Subclipse requires a setting named ssl-client-cert-prompt = yes “in the “Runtime Configuration Area”. This “runtime configuration area” turns out to be %APPDATA%\Subversion\ under Windows. Here, I editted the ’servers’ file and stuck this setting in the ‘[Global]‘ section.
When re-entering the file it comes up with a certificate prompt where I can manually type the location of the certificate. Why there is no ‘browse’ button is beyond me, but alas. After typing the location of the certificate it asks for the passphrase for the certificate and goes to work… …only to bomb out with Propfind errors.
A further google reveals some pointers by the subclipse authors that I might need an ‘unlimited strength’ Java Cryptography Extension. By default, a JRE ships with ‘Strong encryption’, meaning that JCE will use strong ciphers such as DES and RSA, but with limited keysizes (max 128 bits for most). As it turns out, my certificate uses 512-bit RSA. The maximum keylengths are controlled by a policy file. To update to unlimited keysizes, you need to download this file from Sun. Extract the contents of the ‘jce’ folder in the zip-file in %JAVAHOME%\lib\security. Then, restart Eclipse to ensure that it accepts the new policy (I don’t know if this is absolutely required but better safe than sorry).
After the restart, I opened the SVN perspective again and entered the URL, again entered the certificate path and passphrase and lo’ and behold: a SVN repository appeared:
However, when clicking the little + sign, again the dialogs appeared that asked me to input my certificate path and passphrase. I was sure that I had ticked the ‘Save Answer:’ checkbox, but I entered my info again and the second level in the repository appeared. When clicking one of the branches in the tree, again I got the dialogs. It appears that the ‘Save Answer:’ checkbox doesn’t do anything. Rather than entering the certificate and passphrase for every action I take in the SVN Repository explorer, I opted for entering the certificate and passphrase into the SVN configuration file.
This entails entering the following info into the ’servers’ configuration file mentioned above:
ssl-client-cert-file = <location of certificate>
ssl-client-cert-password = <passphrase>
This solved the problem and I could browse the repository without problems afterwards. I checked out my project and moved on to the next task: integrating Trac into Mylyn.
