TLS 1.2 Enabled registry value-"0xffffffff" 0r 1

[Shivani_ra]

Could you please confirm what should be the correct TLS 1.2 "Enabled" registry value-"0xffffffff" 0r 1.

There are multiple articles in internet that refer to each one of these. Does "0xffffffff" value performs same function as decimal value 1? Is this the OS Default value?

We have exchange 2010/2013 servers.

[#2]

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings

To enable the TLS 1.2 protocol, create an Enabled entry in either the Client or Server subkey as described in the following table. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 1.

Hope that helps

Best, Chris

[#3]

@Christopher Hoard it is not 100% sure that it is a value of 1.

Have a look under 

https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls?WT.mc_id

Configuring Schannel protocols in the Windows Registry

You can use the registry for fine-grained control over the protocols that your client and/or server app negotiates. Your app's networking goes through Schannel (which is another name for Secure Channel. By configuring Schannel, you can configure your app's behavior.

Start with the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols registry key. Under that key you can create any subkeys in the set SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2. Under each of those subkeys, you can create subkeys Client and/or Server. Under Client and Server, you can create DWORD values DisabledByDefault (0 or 1) and Enabled (0 or 0xFFFFFFFF).

I know that your article is newer but at the end I think it makes not a difference if you try 0xffffffff or use a 1.

Best regards

Roger

[#4]

I think I would point out for anyone who reads this later that the article cited above has since been updated to match the Windows Server SCHANNEL registry guidelines. To enable, set the Enabled key to 1, to disable, set Enabled key to 0.

https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls?WT.mc_id#configuring-schan...
Configuring Schannel protocols in the Windows Registry
You can use the registry for fine-grained control over the protocols that your client and/or server app negotiates. Your app's networking goes through Schannel (which is another name for Secure Channel. By configuring Schannel, you can configure your app's behavior.

Start with the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols registry key. Under that key you can create any subkeys in the set SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2. Under each of those subkeys, you can create subkeys Client and/or Server. Under Client and Server, you can create DWORD values DisabledByDefault (0 or 1) and Enabled (0 or 1)

[#5]

@nmyron3983  I was trying to understand what that hex value represented since their current guidance doesn't reflect it. You just saved me a lot of searching, thanks!

[#6]

@Roger Vögeli It is not completely clear from the Microsoft docs what the value should be.

It is either specified as 1 or "non zero". 0xFFFFFFFF is clearly non-zero, but I have had tickets with MS Premier support to solve TLS/SChannel issues by modifying the value to 1

The article you refer to does not contain the value 0xFFFFFFFF anymore.

From docs.microsoft.com, clearly 0 or 1 

To disable a cipher, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. When you disable any algorithm, you disallow all cipher suites that use that algorithm. To enable the cipher, change the DWORD value to 1.

and another here too

Start with the  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols registry key. Under that key you can create any subkeys in the set SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2. Under each of those subkeys, you can create subkeys Client and/or Server. Under Client and Server, you can create DWORD values DisabledByDefault (0 or 1) and Enabled (0 or 1).

But not here

In order to override a system default and set a supported (D)TLS or SSL protocol version to the Enabled state, create a DWORD registry value named "Enabled" with a non-zero value, and a DWORD registry value named "DisabledByDefault" with a value of zero, under the corresponding version-specific subkey.

(I have entered a github issue for this page)

It seems that the 0xFFFFFFFF value stems from CIS/DISA STIG baselines, with may be correct (non-zero) but leading to issues if it is not 1.

[#7]

@AndrePKI any news here? A colleague ran Exchange HealthChecker and it reported issues regarding TLS 1.2 Enabled-Key which is 0xffffffff instead of 1 (controlled by GPO in our case)...Not sure if we should set to 1 again...

[#8]

We went to change it to 0x0000001 to avoid any issues, we never saw any to date, which is almost two years now.

[#9]

The latter article (this one)  has been updated to mention "1" as the correct value for Enabled.

[#10]

@AndrePKI 

This is an interesting topic.  I am trying to find out the same answer.

For all our Exchange servers I have set the value to 1 (and configred the keys using their registry settings) as per the HealthChecker scripts requirements.  All TLS checks pass.

On a standard Windows Server 2022 server if I run the latest version of Nartac's IISCrypto tool and select TLS1.2 or 1.3 it changes the value to 0xffffffff.

If we want to run a "standard" across our enterprise it would be nice to have a definitive answer.

To Microsoft I ask "why?" are you not shipping your OS at this level with it enabled and disable TLS 1.0 and 1.1 as standard???

[#11]

On further testing this afternoon, I am leaning towards setting the value to 1. We see a lot of event log errors after establishing an RDP session - A fatal error occurred while creating a TLS client credential. The internal error state is 10013.

In order to fix this you need to fully enable and secure all communication using TLS1.2. I followed all the same steps I did for securing exchange server including setting the .net registry keys, rebooted and the message goes away.