Critical SSL Binding Issue: HTTPS Failures Reported in IIS

Table of Contents

This document addresses a critical problem encountered in Internet Information Services (IIS) versions 7.0 and 7.5 where websites configured with Secure Sockets Layer (SSL) bindings experience failures in HTTPS connections. This issue manifests as an intermittent loss of HTTPS access to the website, while HTTP access might remain functional, contingent on the site’s SSL requirement settings. This article provides a detailed explanation of the symptoms, cause, and resolution for this specific IIS problem.

Symptoms¶

The primary symptom of this issue is the failure of HTTPS connections to a website hosted on IIS 7.0 or 7.5 that is configured with an SSL binding. Users attempting to access the website via HTTPS may encounter browser warnings indicating problems with the SSL certificate. These warnings can range from notifications that the SSL certificate has expired or is not yet valid, to alerts that the website name is incorrect or does not match the certificate. Despite these HTTPS connection failures, users might still be able to access the website using HTTP, assuming the site is not configured to strictly enforce SSL connections.

Further investigation by a site administrator using IIS Manager to examine the SSL settings of the affected website might reveal that the SSL bindings have been unexpectedly removed. In some cases, the original SSL bindings are not entirely deleted but are replaced with invalid certificate binding information. This corruption or deletion of SSL bindings directly leads to the HTTPS connection failures observed by users. Complementing these observations, the system event log will typically record an event indicative of the problem.

A warning event, logged under the System event log, with the source “Microsoft-Windows-HttpEvent” and Event ID 15300, is a strong indicator of this issue. This event explicitly states “SSL Certificate Settings deleted for Port : x.x.x.x:443”, where x.x.x.x represents the IP address of the server and 443 is the standard port for HTTPS traffic. The presence of this event log entry, in conjunction with the described user-facing symptoms and SSL binding discrepancies in IIS Manager, definitively points towards this specific SSL binding issue.

Cause¶

The root cause of this SSL binding issue lies in a legacy property related to SSL certificate hashes from older versions of IIS, specifically IIS 6.0. This legacy property, residing within the <CustomMetaData> section of the applicationHost.config file, interferes with the current SSL bindings configured for the website in IIS 7.0 and 7.5. The conflict arises during the initialization process of the Application Base Objects (ABO) mapper, a component used by applications and services that rely on IIS metadata.

When an application or service that utilizes the ABO mapper starts, it attempts to initialize the ABO tree structure. This initialization involves reading configuration data from the applicationHost.config file, including the <CustomMetaData> section. During this process, IIS attempts to map properties from the <CustomMetaData> section into the ABO tree. It is during this property mapping phase that the legacy SSL certificate hash property causes problems.

The presence of this legacy property triggers IIS to delete the currently configured and valid SSL bindings in HTTP.SYS, the kernel-mode HTTP listener for IIS. Subsequently, IIS attempts to recreate a new SSL binding using the value of this legacy hash property. If, as is often the case, this legacy hash value is invalid or outdated, the attempt to add a new, valid SSL binding in HTTP.SYS fails.

This failure to establish a valid SSL binding in HTTP.SYS results in the website lacking the necessary IP address and port combination associated with a valid SSL certificate. Consequently, when users attempt to connect to the website over HTTPS, the connection fails because HTTP.SYS is unable to locate a valid SSL binding for the requested website. The issue is therefore directly attributable to the interference of this legacy SSL certificate hash property, disrupting the proper SSL binding configuration and leading to HTTPS connection failures.

Resolution¶

The resolution for this critical SSL binding issue is to remove the problematic legacy SSL certificate hash property from the applicationHost.config file. This property is located within the <CustomMetaData> section of the configuration file. Specifically, you need to locate and delete the <key> element with the path attribute path="LM/W3SVC/X", which contains a <property> element with the id="5506".

To implement this resolution, follow these steps:

1. Open File Explorer: Navigate to the IIS configuration directory. The default path for this directory is typically C:\Windows\System32\inetsrv\config.
2. Locate applicationHost.config: Find the applicationHost.config file within this directory. It is crucial to back up this file before making any modifications. Copy the file to a safe location as a backup.
3. Open applicationHost.config in a Text Editor: Open the applicationHost.config file using a text editor with administrator privileges, such as Notepad run as administrator. This is necessary to ensure you have the permissions to save changes to the file.
4. Locate the <CustomMetaData> Section: Scroll through the applicationHost.config file and find the <customMetaData> section. This section is typically located within the <configuration> and <system.applicationHost> sections.
5. Find the Problematic <key> Element: Within the <CustomMetaData> section, search for the <key> element that has the attribute path="LM/W3SVC/X".
6. Identify the <property> Element with id="5506": Inside the <key path="LM/W3SVC/X"> element, verify that there is a <property> element with the attribute id="5506". This is the legacy SSL certificate hash property that needs to be removed.
7. Delete the <key> Element: Delete the entire <key path="LM/W3SVC/X"> element, including both the opening <key> tag and the closing </key> tag, as well as all the content within it (which should include the <property id="5506".../> element).
8. Save the Changes: Save the modified applicationHost.config file.
9. Restart IIS: Restart the IIS service for the changes to take effect. You can do this by opening a command prompt as administrator and running the command iisreset.

After performing these steps and restarting IIS, the legacy SSL certificate hash property will be removed. This will prevent the interference with the current SSL bindings, and HTTPS connections to the website should be restored.

The code snippet below shows the XML element that needs to be deleted from the applicationHost.config file:

<key path="LM/W3SVC/X">
     <property id="5506" dataType="Binary" userType="1" attributes="None" value="oXiHOzFAMOF0YxIuI7soWvDFEzg=" />
</key>

More Information¶

The 5506 custom property, as mentioned earlier, is a legacy feature originating from IIS 6.0. In IIS 6.0, this property was utilized to store an SSL certificate hash value. This mechanism was part of the configuration system in IIS 6.0, but it is no longer relevant or necessary in IIS 7.0 and later versions. The current SSL configuration in IIS 7.0 and 7.5, and subsequent versions, employs a different, more robust method for managing SSL bindings.

The issue arises because the ABO mapper, when initializing in IIS 7.0 and 7.5, attempts to process all properties it encounters in the <CustomMetaData> section, including this legacy 5506 property. During the mapping process, the system incorrectly interprets this legacy property and takes the action of deleting the current, correctly configured SSL bindings in HTTP.SYS. It then attempts to recreate the SSL binding using the outdated or invalid hash value associated with the 5506 property.

Since the legacy hash value is typically no longer valid or relevant to the current SSL certificate, the attempt to recreate the SSL binding fails. This leaves the website without a proper SSL binding in HTTP.SYS, thus causing HTTPS connection failures. The website essentially loses its ability to serve content over HTTPS because the necessary configuration linking the website to an SSL certificate on port 443 is missing or corrupted.

Steps to Reproduce¶

To demonstrate and reproduce this issue, you can manually add the legacy SSL certificate hash property to the <CustomMetadata> section of the applicationHost.config file. Adding the following XML code snippet will simulate the presence of the problematic legacy property:

<key path="LM/W3SVC/X">
    <property id="5506" dataType="Binary" userType="1" attributes="None" value="oXiHOzFAMOF0YxIuI7soWvDFEzg=" />
</key>

To reproduce the issue:

1. Open applicationHost.config: Navigate to C:\Windows\System32\inetsrv\config and open applicationHost.config in a text editor with administrator privileges. Remember to back up the file first.
2. Locate <CustomMetadata>: Find the <CustomMetadata> section within the file.
3. Add the Code Snippet: Insert the XML code snippet provided above into the <CustomMetadata> section.
4. Save the File: Save the modified applicationHost.config file.
5. Launch IIS Manager or Use ADSUTIL: Launch the IIS Manager (Inetmgr.exe) or use the ADSUTIL.vbs script to enumerate the metabase. These actions trigger the ABO Mapper initialization process.
6. Observe the Issue: After launching IIS Manager or using ADSUTIL, attempt to access a website on the IIS server via HTTPS. You should now observe the symptoms described earlier, including HTTPS connection failures and potential SSL certificate warnings in the browser. Also, check the system event log for Event ID 15300.

By following these steps, you can reliably reproduce the SSL binding issue caused by the legacy 5506 property and verify the resolution by removing this property as described in the “Resolution” section. This reproduction method serves as a practical demonstration of the problem and the effectiveness of the provided solution.

We encourage you to share your experiences and questions in the comments below. Have you encountered this specific SSL binding issue in your IIS environment? What steps did you take to resolve it? Your insights and questions are valuable to the community.