Tuesday, February 19, 2008

Wildcard SSL Certificates and second-level domain names

Today we were trying to get the SSL port for a second QA website hosted on IIS 6 to work. For our development purposes, we have a trunk for our codebase and then a branch. For our QA purposes, these two sites are deployed to different sites on a particular QA machine.

First off, we are using host header values to share the same IP/port combination so that our QA teams doesn't have to hit the second branched site on any particular port. Once the host header was set up, the next step was to set up the SSL port. We have an SSL certificate set up on the trunk site and it's working fine however when we tried to setup the second branched site, IIS would serve the page under the main trunk's site when we hit a protected page. Really bad!

This is how I came across Wildcard SSL Certificates.

It's only useful when the second-level domain names are identical, which in our case was. For example, let's say you have a host header setup on a, e.g. QA box, as qa.xyz.com and the second site's host header is set up as branch.qa.xyz.com. This is a good example when you can utilitze a wildcard SSL certificate.

Here is a good explanation of a CA on this topic: http://www.verisign.com/ssl/wildcard-ssl-certificates.html


The way to configure a wildcard certificate is to go through the same normal process in IIS, but for common name make sure you enter *.xyz.com. Once you receive the SSL certificate, assign it to the websites with the same second-level domain names configured on that IIS.

For more info: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5d0fb4c2-3333-4fec-82fc-6e15d3733937.mspx?mfr=true