Performing an In-Place SSL Cert Request While Avoiding Downtime

If you’ve ever had to upgrade an IIS site from using an internal or self-signed SSL certificate to using one created through a trusted Certificate Authority, you know about the down-time window. That is, when you create a new certificate signing request through IIS, it overwrites your existing SSL information within the metabase, leaving your website in a state of limbo until the request is processed.

Usually, this isn’t a problem since SSL certificates can be provisioned in a matter of minutes through many providers. In those cases, the SSL transition can be scheduled as part of regular maintenance.

Recently, however, I ran into a situation where a client’s SSL certificate signing request would take days due to various regulations. Their internal policies mandated a third-party had to issue the request, pass it on to another group, and so on. In many cases, this wouldn’t be an issue, but since we didn’t have access to dedicated servers for Test and Staging, the outage prevented testers from doing their work.

At this point, I’d like to highlight how important a proper development pipeline is. Whenever possible, dedicated environments should be available for Development, Testing, Staging, and Production. Some project managers further break the categories to include User Acceptance Testing and other categories, but I consider four to be a good starting point. Keep in mind that these don’t have to be dedicated machines — virtualization often makes sense.

In my case, I considered three options to ease the transition:

• We could cancel the IIS certificate request, revert to our self-signed certificate, and re-issue the request using CertReq.exe. This command-line tool can create valid requests without impacting existing IIS sites. I decided against it, however, because it would have required us to restart the CSR process, leading to additional delay.
• Since I was working with a SharePoint site, I could have extended the application to a new zone and assigned the appropriate Alternative Access Mapping. This would have allowed users to access the content, although doing so would require bookmarking a new address. The usability challenge, coupled with the additional steps (copying binaries and adjusting web.config), led me away from this idea.
• I could clone the site and leave its request active while using the identical site’s old certificate. The process would involve copying the site’s metabase definition, stop the original site with the pending request, activate the clone, and then revert the cloned site to using our self-signed certificate. If done right, it would only take a few minutes of my time, and would be transparent to end-users. This is what I decided on.

The process of creating a placeholder site ended up being painless. I originally performed this on IIS 6.0 using MetaBase Explorer. I then figured out how to do the same on IIS 7.0 using AppCmd.exe. In both situations, I had to manually edit the XML after exporting to clean up references to the old site identifier.

I’ve since figured out the easiest way: using ADSUtil.vbs. Its "copy" command updates all internal ID references, allowing for a one-line site duplication.

Performing an In-Place SSL Cert Request While Avoiding Downtime (ADSUtil.vbs)

1. Find the IIS site identifier

   This is the unique ID that IIS uses in its internal metabase. It usually consists of 9 or 10 seemingly random digits. The easiest way to find this is to open the IIS Manager and click on your server’s "Web Sites" category header. Doing so should present a list of all sites, displayed with Name and Identifier, in the right-hand panel.

2. Run the appropriate ADSUtil.vbs command

   If you’re not already familiar with ADSUtil.vbs, it’s a handy script for performing IIS administration. In a default installation, it can be located within "C:InetpubAdminScripts". The command we’ll use clones the IIS definition for any site when provided the source identifier and new target ID. Run the following command:

   CScript.exe C:InetpubAdminScriptsADSUtil.vbs copy w3svc/123456789 w3svc/987654321

   In the above example, replace "123456789" with the identifier of your source IIS side (as found in step 1), and "987654321" should represent a new unique ID. Once completed, a duplicate site should be created.

3. Stop the current site; provision and start the new site

   The next step I’d recommend is to rename the new copy of the site to something intuitive. Otherwise, it’s easy to confuse the new copy with the old and run into more headaches. The new one is easy to identify, since it will initially be in the "Stop" state (due to port usage conflicts).

   Once the new site is renamed, stop the old site. Next, go into the new site and change the SSL settings to utilize our previous (working) certificate. Once completed, start the site as normal. If done correctly, things should be working as before.

4. When the new certificate is ready, install it then switch the active sites

   As soon as the new certificate has been generated and is ready for import, process the change using our old (currently stopped) site. Then stop (and optionally delete) the temporary placeholder. Finally, re-start the original site as before.

Keep in mind that each start and stop of the IIS site will be a hard refresh wiping out session data and requiring pages to be recompiled. It sure beats a hibernating port 443, though!