Disabling TLS 1.0 on Windows Server 2016 Essentials without breaking client-to-server operations

James White
3 min readJan 23, 2022

These days having anything below TLS 1.2 enabled on a server or client is technically reduced security and will also be an issue for PCI DSS compliance (if required). Sometimes disabling TLS versions outright can cause issues with other applications if they are not instructed or able to handle newer TLS versions properly.

Windows Server 2016 Essentials is one of the many examples of having full TLS 1.2 support but some functionality and features needing to be specifically handled in order to be able to fully disable TLS 1.0 support entirely. This relates to the Windows Server Essentials client-to-server operations like connecting clients to the server and client computer backups. Without careful handling, the lack of TLS 1.0 being available on the server will break these functions.

The steps to achieving this are:

  1. Enabling TLS 1.2 both for server and client on Windows Server 2016 Essentials itself (if not already enabled). You can also take this opportunity to audit and disable any older TLS versions.
  2. Setting two important registry keys for the .NET framework on the server and any client that’s connecting to Windows Server 2016 Essentials.
  3. Reboot your Windows Server and any client connected for these changes to be made.

Enabling TLS 1.2 and disabling older TLS versions on the server

I’ve prepared a registry file which adds the appropriate registry values for disabling SSL 2.0/3.0 (I really hope this still wasn’t enabled!) and TLS versions lower than 1.2. It also ensures TLS 1.2 is enabled. A reboot will be required to modify anything related to SCHANNEL.

The registry keys are based off Microsoft’s guidance around enabling or disabling certain SSL/TLS versions. It can also be done with PowerShell, but ultimately doing it via PowerShell is still writing to the registry.

Allowing the .NET Framework to use strong cryptography and the TLS configuration of the operating system

These registry keys need to be deployed on the server and any client, connecting to a Windows Server 2016 Essentials server. These registry keys ensure applications using the .NET Framework use strong cryptography and allows client to use the TLS version configured by Windows.

Microsoft have a specific documentation article about these registry keys. Because of this being tied to the .NET Framework is will relate to many other applications using this framework such as Microsoft SQL Server and is not exclusive to Windows Server 2016 Essentials. It just so happens that the connector software uses the .NET Framework quite extensively.

A reboot is also required for any of the registry changes to the .NET Framework to take effect.

Summary

After rebooting both the server and any client with the registry changes described above, you should find that any client is connecting to Windows Server 2016 Essentials with TLS 1.2 only. You can test with Windows Server Essentials Dashboard to confirm if the server can see any clients connected with the status being “Online” along with running a backup to ensure the client-to-server operations work.

Additional notes

  • There is no TLS 1.3 support in Windows Server 2016 with SCHANNEL. Windows Server 2022 does support TLS 1.3 with SCHANNEL.
  • TLS 1.0 should not be outright disabled on older Windows Server versions as this will impact more then just client-to-server functionality.
  • Disabling TLS 1.0 on Windows Server 2016 Essentials can have some side effects on the Windows Server Essentials connector software being able to automatically discover the server, this may require manually providing the server hostname when adding a new client.
  • If you use a personalised Microsoft domain for anywhere/remote access, you may have to temporarily enable TLS 1.0 to allow communication to Microsoft for assigning the domain to your Microsoft account. If you use your own custom domain/SSL certificate, you should not have to do this.

--

--

James White

I'm a web developer, but also like writing about technical networking and security related topics, because I'm a massive nerd!