First there was the fact that a self signed certificate wouldn’t do. This wasn’t a big surprise, but it wouldn’t even allow me to test my app to ensure it was working before I forked out the big bucks for the proper SSL certificate.

I had an idea, I have a code signing certificate from Thawte that is worth a pretty penny, surely it will at least allow me to test my app, if not be my solution. Strike 2. A Code-Signing certificate can only be used to sign code (JARs in my case), not for authentication – again, no real surprise.

So an SSL certificate was purchased from a company we have a good relationship with, so we got it for wholesale price and away we went… almost. Java’s Virtual Machine looks in a certain spot for trusted certificates, but unlike the major browsers, only has about 15 in there. Of course the certificate we bought was not one of them. Strike 3 – back to the drawing board. For anyone reading this because they are experiencing similar problems, use:

keystore –list –v –keystore %JAVA_HOME%/lib/security/cacerts

Password: changeit

to view the certificates that are in that cacerts file. This is the default file java will look in if you do not specify a trustStore property when calling your applet/application.

We found a certificate in here, were able to obtain a refund on the previous and now it was time to invoke methods remotely over secured sockets and love life… nearly.

The first test of this saw love. The problem was that test didn’t bring browsers into play. I ran the RMI Registry and the Server Implementation, downloaded the jar and ran it from the command line on my PC. Voila!

Hello World!

I was ecstatic. Until I ran the applet from the same jar and got an error telling me “bad certificate�. This didn’t make sense as the root CA of the certificate we were using was certainly in the browser (both Firefox and IE7). A bit of looking around the forums provided very few answers so I decided to post myself (I very rarely post on java forums as the answers to my questions are there if I look hard enough).

It turns out that the Root CA certificates in the browsers have a property that specifies what actions a certificate using that Root CA can perform. The certificate we were using was marked for Code Signing, Server Authentication, Email Authentication. Notice Client Authentication missing. *sigh*.

This was getting thoroughly annoying as I have now spent 3 weeks trying to test code that only took me a couple of days to fully merge with the older code.

I tried checking the Client Authentication box in the browser for out certificate provider, but this didn’t fool the browser for a second, and I was still denied. After a long chat with an RMI expert, it was concluded that it is not currently possible to enable client authentication in RMI using SSL in an applet. If the application is not running from a browser however, this works as it should. The reason is that when you use the browser, it looks for the certificate there rather than in the parameters specified by the applet.

The work around is buy one of the (I think) 2 certificates that support client authentication, though this is untested as we added security other ways and as such, didn’t purchase one of these certificates.

The applet is now running with SSL enabled using Remote Method Invocation. Hurrah!