Recently seen in the IIS newsgroup was the following problem:

We have a Dell Powervault 745N running Windows 2003 standard, SP1. We have generated and installed an SSL certificate from rapidssl (geotrust) in IIS and it works ok.

However, upon reboot, when we check the IIS certificate settings in the virtual directory, we can see that IIS is once again using the old, machine certificate. ... No error messages in the event log. ... The IIS metabase is working ok otherwise - does not appear to be corrupt as other settings I change seem to stay as part of the config.

The first step is to verify that the correct SSL certificate information is actually being persisted into the IIS metabase. To do that, we look at the website's properties in the metabase, particularly the SSLHash property, as shown below.

SSLHash Property

We then verify that this is the correct certificate that should be used. To do that we use the Certificates MMC Snapin to examine the computer's certificate store. To do this click Start - Run - MMC.exe

Inside MMC.exe click File - Add/Remote Snapin. add the Certificates snapin and point it to the Computer account when prompted.

Expand the Personal - Certificates nodes and locate the certificate that you want IIS to use (the certificates should be listed by their common name so you should be able to locate the one you want easily). Double-click the certificate to bring up its properties, and on the details tab scroll down to the thumbprint property. Verify that the value for the thumbprint is the same as the SSLHash stored in the metabase. If it is, then you know that IIS is currently configured (both in-memory, and in the metabase) to use the correct certificate.

Certificate Properties

Since the correct certificate has been persisted to the metabase, the change in certificate must be caused by some external agent. The next step is to enable Metabase Auditing. This enables us to see what process or user account is making changes to the metabase, what they are changing, and the old and new values. Detailed steps on enabling metabase auditing are available here.

In the current situation the following event was logged, indicating that a program called taskcord.exe was changing the SSLHash value in the metabase

Primary User Name: SYSTEM
Primary User Domain: NT AUTHORITY
Primary Logon ID: (0x0,0x3E7)
Path: /LM/W3SVC/6633
Property ID: 5506
Property Name: SSLCertHash
Old Value: 84 37 c2 d0 61 --snipped --
New Value: d7 48 f1 ba 6b --snipped --
Caller PID: 2776
Caller Image Path \WINDOWS\system32\ServerAppliance\taskcord.exe
Result: 0x0

A quick search turns up the following MSDN documentation on TaskCord. The Task Coordinator stores it's jobs in the registry at HKLM\SOFTWARE\Microsoft\ServerAppliance\ApplianceManager\ObjectManagers\Microsoft_SA_Task. Under the ApplianceInitializationTask key there was a task called SelfSignCert.SelfSignCert.1, which was run each time the box was booted. That task was causing a self-signed certificate to be generated and applied to the default website each time the box was booted. Removing that entry stopped the SSL certificate from being changed. Case closed!

On a completely unrelated note, I graduated with a Masters of Business and Technology (MBT) from the University of New South Wales last Friday (24th).