In previous TechRepublic posts I described some of the pitfalls I encountered when renewing existing SSL certificates, specifically one for Exchange on IIS7 and one for an SSL VPN appliance. More recently we decided to buy a wildcard certificate to meet a range of requirements, so I had to add another string to my SSL bow and figure out what to do.

Why wildcard?

The decision to go for a wildcard certificate was based on a combination of purchase cost and convenience.

  • I had to renew an existing single-domain certificate on one IIS6 server (say server.companyname.com).
  • I needed to add one to another IIS6 server (say server2.companyname.com).
  • We were going to need one for our main website (e.g., www.companyname.com).
  • In a year’s time I’ll have to renew the one for my SSL VPN appliance (e.g., remote.companyname.com).

While the numbers didn’t quite add up on pure purchase cost, the hassle of buying and renewing four separate certificates made it worthwhile to buy the wildcard variety that covers any variant of “companyname.com” (usually denoted as *.companyname.com).

Initial purchase

My chosen supplier was Go Daddy. Yes, I know they had their problems recently, but we don’t use them for Web hosting, and I was used to dealing with them. What’s more, they don’t charge extra for securing multiple servers — which a wildcard certificate will be used for.

After logging in to their site I selected the 3-year wildcard SSL, entered payment information, and was taken to the receipt page. At this stage all I’d done is buy a product in principle. To get started I did the following:

  1. Clicked My Account, which took me to a list of my products.
  2. Expanded SSL Certificates. This showed my new certificate with a Set Up button next to it.
  3. Clicked Set Up. This gave a confirmation message telling me to go back into the account to set up the certificate. (I found this rather strange, considering that I’d just clicked a button called Set Up!)
  4. Refreshed my list of products again. Now the wildcard is labeled NEW CERTIFICATE and has a Launch button next to it.
  5. Clicked Launch. This took me to my Secure Certificate Services page.
  6. Using the “folder tree” on the left-hand side, I clicked Credits and then Click Here To Update Your List. This gave the screen shown in Figure A.

Figure A

Click the image to enlarge.

Certificate Signing Request

Clicking the Request Certificate link seen in Figure A opens the Certificate Signing Request (CSR) screen, waiting for me to paste in my CSR. For my previous single-domain certificates I generated the CSR on the specific server or device where I planned to install it. For the wildcard certificate I wasn’t sure what to do, since in theory it could be installed anywhere.

For my first attempt I tried to create the CSR on the first IIS6 server where I intended to use the wildcard certificate. I tried to follow Go Daddy’s instructions but came unstuck because there was no option to Create A New Certificate; this was because there was an existing self-signed certificate installed, which made the options different. If I’d tried to use the Renew option, that would have given me a CSR for a single domain (i.e., server.companyname.com).

I tried on another IIS6 server where there was no certificate, and this time Go Daddy’s instructions worked. The Common Name is the most important field to get right, so I made sure it was *.companyname.com. After naming and saving the CSR (just a text file), I pasted the contents into the Go Daddy form. A confirmation screen told me I’d requested the correct domain name. Clicking Next gave me instructions to check my Pending Requests. This again refers to one of the “folders” on the Secure Certificate Services page.

Verification

The request was “pending” because the certificate now had to go through a Domain Control Verification procedure. This was pretty much a repeat of the process I described for the IIS7 certificate, using the Domain Zone Control method. The only hiccup was that I had to try the final validation link four times before it worked.

Download and installation

I received two emails. The first email verified approval, and I checked that the Pending Request had disappeared and my new certificate was listed as Current. The second email confirmed that the certificate had been issued and gave download instructions. The end result was a Zip file containing a .crt file and a .p7b file.

Turning again to Go Daddy’s knowledge base, I had a false start trying to follow them on the server with the self-signed certificate. I realized I needed to install the wildcard certificate on my other IIS6 server (where I generated the CSR) and then export it for use on the first one.

Wow, I’m glad this isn’t complicated.

So…back on that first server I successfully imported the intermediate certificate and then followed the steps in IIS, choosing the Process The Pending Request And Install The Certificate option. Success.

To export from this server I re-ran the IIS Certificate Wizard and selected Export The Current Certificate To A .pfx File. After choosing a folder to store the file, I also had to supply a password to encrypt the .pfx. Then, on the server where I really wanted the wildcard certificate, I followed these instructions to import the certificate from the .pfx file into the certificate store, supplying the password when requested. I also checked Mark The Key As Exportable, as recommended by Microsoft. Finally I ran the IIS Certificate Wizard, clicked Assign An Existing Certificate, chose my wildcard, and set it to use port 443. Success.

Summary

By using a wildcard certificate, it now enables us to secure any number of servers and variants on our domain name. There are hurdles to overcome when purchasing and installing, but in the long run this will save us time and money.