Unfortunately issues can arise when third-party tools are used to modify TLS settings on a Windows Server. While these utilities are often intended to simplify the process of hardening or tuning protocols, they can introduce serious side effects. Especially in environments running applications like Exchange Server, IIS or other components that depend on schannel. Misapplied registry changes, unsupported cipher suite configurations, or incomplete protocol disabling can lead to failed connections, service start-up errors, or degraded security posture. It should also be noted that not all of the changes made may be officially supported.
This post will look at a case where the Exchange Health Check script detected issues with how TLS was configured on an Exchange server. This was in part due to an ancient and already depreciated version of the 3rd party tool being used.
TLS Background
On Windows, SSL and TLS are implemented through the schannel (Secure Channel) security support provider, which is part of the Windows Security Support Provider Interface (SSPI) framework. Schannel is responsible for handling all SSL/TLS protocol negotiation, certificate validation, key exchange, and encryption operations used by Windows components and applications such as IIS, Exchange Server, RDP, and .NET applications. Rather than each application implementing TLS independently, they call schannel APIs, which rely on configuration data stored in the Windows registry under this path:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL.
Each protocol (e.g., SSL 2.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3) contains two subkeys Client and Server.
The Client and Server keys can have values of
-
Enabled (DWORD)
- DisabledByDefault (DWORD)
The documented data settings for these DWORD values are:
Enabled = 1→ Protocol enabledEnabled = 0→ Protocol disabled
This is something to remember, and we will circle back to what is documented and supported further on in the post. The protocol enablement/disablement that is achieved in the registry using the keys as noted here: Transport Layer Security (TLS) registry settings | Microsoft Docs
Schannel's centralised design allows administrators to control supported protocol versions, cipher suites, and hashing algorithms consistently across the operating system. Updates to schannel can introduce new protocol support (such as TLS 1.3 Server on Windows Server 2022 onwards) or remove deprecated options. This help ensure that Windows maintains compliance with evolving security standards while providing a unified, manageable SSL/TLS implementation. Granted there were issues in the past where the application would implement it's own configuration for TLS, that management issue has come a long way. The main culprits such as Exchange and older versions of .NET now use schannel as the main configuration source.
For more TLS implementation details please see:
Cipher Suites in TLS/SSL (Schannel SSP) - Win32 apps | Microsoft Docs
Now, onto issues caused by modifying TLS settings outside of approved tools.
Old Version of IISCrypto
In this case the customer had downloaded a version of IISCrypto years before, and since it appeared to work they had never checked for a newer or updated version. There were using version 1.6 of IISCrypto.
To replicate the situation, that version was downloaded from the deprecated page. Note that this is NOT the recommended version nowadays.
To have a fair test, the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols key was deleted so we can see exactly what additions/modifications would be made. That way there would be no Client or Server keys present prior to the tool making its changes.
Enabling TLS 1.0, 1.1 and 1.2
Initially TLS 1.0, 1.1 and 1.2 were set as enabled. This is to match what the customer had configured.
The settings were applied. Since schannel is initialised at boot time, we need a restart to apply the changes.
After restarting the server, the Exchange Health Check was run. Note that there is some angry red text regarding the TLS configuration.
The error text was:
Client Disabled By Default: False
Error: Mismatch in TLS version for client and server. Exchange can be both client and a server. This can cause issues within Exchange for communication.
In short there is a misconfiguration between the client being disabled, but was enabled by default. Make sure you are factoring the double negative! This was consistent for each protocol TLS 1.0, 1.1 and 1.2.
Enabling Only TLS 1.2
Ok - test two. Let's only enable TLS 1.2 as that is really what we should be using nowadays. What does that do when we apply that and restart the server.
This time around, only the Server Keys are set., no Client keys were added.
But note what was written into the values - it was 0xFFFFFFFF
That is NOT what should be used nowadays. That is an unsupported value on this version of Windows. The values that are documented and supported are 0 and 1. Basically Boolean logic to enable/disable the particular item.
Current IISCrypto
If we download a current version of IISCrypto and compare the outcomes, what do we see?
Verison 3.2 of IISCrypto was downloaded. As per the current Exchange Team and industry directives, TLS 1.0 and 1.1 were disabled. Only TLS 1.2 should be enabled.
Note that this version does a much better job of applying the settings.
But we still have the wrong value entered into the Enabled value in the registry.
This is what the "Override Enabled" setting in the tool is for. If we use that and then set the values, there is a difference.
Using the "Override Enabled" option, note that the expected and supported value is now present.
Update 8-10-2025 - Note that IISCrypto has been further updated. Version 4.0 no longer has the "Override Enabled" option. All protocols now set Enabled to 1
Cheers,
Rhoderick
