WS-Security with X.509 certificates

I tried several different tools to create reasonable X.509 certificates for WS-Security scenarios in the last few weeks. There are a lot of tools. You could use

• MakeCert (Microsoft)
  
• Keytool (Sun)
• CertGen (Bea)
• OpenSSL
• and there are others...

My first and biggest mistake was, that I tried to use the same certificate (and its private key) for different server side technologies.
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:

1. Use your computer's name as subject name in the certificate
2. Set up the test certificate in a test web site on your machine, which is secured by SSL
3. Test whether you can reach the site via https
4. Now you can be sure your certificate is installed properly and is trusted
5. Use this certificate in WS-Security scenarios.

Important: Repeat these steps for each of your server environments. Different web servers use slightly different certificates (see the Verisign sites - they want to know which is your environment). The odds are good that your certificate will work fine in WS-Security scenarios, if they work for SSL in the same technology stack...
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...

Heading for Munich

I'm just on my way to Munich. I'm giving a talk about Web Service policies and interoperability at OOP 2006 together with Klaus Alfert. It's gonna be fun. We're giving a high level overview on WS-* standards and drilling down into some interop scenarios between .NET 2.0/WSE3, BEA WebLogic Workshop 8.1.5 and Suns JWSDP 1.6.
Preparing this talk and one of the security demos, we both learnt lots about getting, storing and using X.509 test certificates and about the different tools managing them. It's a kind of nightmare, if you try to get the same certificate working on different server platforms. I'll post some more details on my experiences in this area in the next week...