SSL certificate occasionally disappears from HTTPS binding

TLDR: A couple of Metabase compatibility entries referring to SSL may interfere with the server certificates that are used in HTTPS bindings.

Symptom

Occasionally, the SSL certificate which is used for the HTTPS binding gets no longer selected in the drop-down of the binding editor.

Because it disappears from the selection, the site is no longer accessible via HTTPS, forcing the administrator to regularly go an re-select the certificate in the HTTPS binding of the site.

The certificate is still there on the machine, very much valid and otherwise working just fine.

In my case, the certificate was disappearing about each week, possibly corelated with a machine or IIS restart.

This behavior was accompanied by entries in Windows Events Viewer, System log, by Microsoft-Windows-HttpEvent:

Event ID 15300: ”SSL Certificate Settings deleted for endpoint : 0.0.0.0:443”.

As a side note, when selecting an SSL certificate for an HTTPS binding, this selection results in a Registry entry. This is how it gets saved. The entries may be found under

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo

Later, the HTTP.SYS driver is using those entries to determine what certificates will be used for the TLS negotiation on that HTTPS binding; see my article at http://linqto.me/https.

Cause

This unpredictable behavior was caused by some garbage Metabase entries in the configuration of the web server. To be exact, the IIS configuration file – applicationHost.config – contained lines like this:

   <!--
        The <customMetadata> section is used internally by the Admin Base Objects
       (ABO) Compatibility component. Please do not modify its content.
   -->
   <customMetadata>
       ...
       <key path="LM/W3SVC/1">
           <property id="1018" dataType="DWord" userType="1" attributes="Inherit" value="1" />
           <property id="5511" dataType="String" userType="1" attributes="Inherit" value="MY" />
           <property id="5506" dataType="Binary" userType="1" attributes="Inherit" value="AW8i2ZlfoxwHixr8iEgK/K7TL94=" />
       </key>
       ...
   </customMetadata>

Looking up for the meaning of these keys, I found that

• Property ID 5511 means SSLStoreName, see https://docs.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525311%28v%3dvs.90%29
• Property ID 5506 means SSLCertHash, see https://docs.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525719%28v%3dvs.90%29

These Metabase entries were conflicting with the certificate selection for the HTTPS binding; once commented out, the SSL certificate selection was no longer reset.

More details

The Metabase.XML was the configuration system used by old IIS 6.0, shipped with Windows XP or Windows Server 2003. It was monolithic and the settings had IDs instead of names, making it very hard to read and configure outside the management console or configuration API.

Since IIS 7.0, shipped with Windows Vista and Windows Server 2008, the IIS configuration was completely re-architected, now based on the applicationHost.config repository.

The Metabase configuration system had an API used to config IIS. That Metabase API is still used by a few apps that need to read or change the IIS configuration. Some of these apps are from Microsoft, like Exchange or SQL Server Reporting Services.

Since IIS 7.0, the Metabase API is saving settings in applicationHost.config. Modern IIS modules are not using those Metabase settings, they would ignore them. But other apps or services might act on those legacy entries. In our case, the Admin Base Objects used for compatibility with IIS 6.0 would indeed read and use those Metabase entries.

The presence of those entries would trigger the ABO: an attempt to lookup for the specified certificate. If found and valid, the certificate would be used; if not, any certificate selection for the HTTPS binding would be removed.

So, while the modern IIS configuration would establish a certificate for the HTTPS binding, the ABO would later remove that selection. The conflict is due to the certificate ID from the Metabase setting: it is simply wrong. Instead of fixing, we opted for commenting out.