- MakeCert (Microsoft)
- Keytool (Sun)
- CertGen (Bea)
- and there are others...
The problem is that the different technologies use completely different key stores (Java Key Stores JKS vs. Microsoft Certificate Store). This means you have to export and import certificates and their private keys from one certificate store and import them elsewhere. This sounds quite simple, but it is not, given the fact that there are several different formats for serialising X.509 certificates into files. Microsoft prefers PKCS12 and uses *.pfx files, if you export certificates from the Windows certificate store. It's not that simple to get those files imported into a Java key store. The easiest way we found to get them into a JKS is the PKCS12Import utility in Sun's JWSDP 1.6.
You can do this and it works - but: your test certificates do look like test certificates. Professional certificates for use in production - as they are issued by Verisign, e-Trust or others - look quite different. They contain lots of information in the subject entries and have a trust chain back to the trusted root certificate.
So I prefered a completely different way to be close to production reality: I ordered SSL test certificates from Verisign and used them in our demos. These certificates are usually bound to your web server and this is a perfect test environment:
- Use your computer's name as subject name in the certificate
- Set up the test certificate in a test web site on your machine, which is secured by SSL
- Test whether you can reach the site via https
- Now you can be sure your certificate is installed properly and is trusted
- Use this certificate in WS-Security scenarios.
A last important note: If you want to use these certificates in Web Services that are secured via SSL and transport layer security, be careful to use the correct URL on your client site: While http://localhost/MyService.asmx might work, the same might not be true for https. The certificate wasn't issued for a machine called localhost, so it will reject calls form the client. You must use your machine's name in the URL, in my case this worked fine:
https://fran0111/MyService.asmx, because fran0111 is my machine's name and is the subject name in the test certificate I used in the service's security policy.
I hope this post prevents you from some of the mistakes I did using certificates. It all sounds quite easy - but I'm afraid it isn't. Not for interoperability scenarios...