Abstract: This short howto goes true the steps to disable TLS 1.0 (and therefore leave only TLS 1.1 and TLS 1.2 activated) on an Microsoft SharePoint Server.
As the payment Card Industry Security Standards Council (PCI SSC) recently announced that TLS 1.0 will be no longer secure (in PCI 3.1) after 2018-06-30 it is now the right time to consider some updates on the affected environments.
Disabling TLS 1.0 on Windows Server 2012 R2 / 2008 R2 is quite easy via the following registry entry (as outlined here):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
However as you might have already disabled SSL 2.0 and 3.0 you would end up in having no protocols enabled. So make sure that TLS 1.1 and TLS 1.2 are enabled via:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
Note: ffffffff is the same as 00000001
Then you need to do an OS reboot and you are almost fine.
To check if that is working as expected you can run an NMAP against the port 443 (assuming you have an IIS webserver installed or against the RDP port 3389) as mentioned here.
BUT that will start to cause all kind of connection issues. So this howto will drive true some of them and outline the solutions in order to fix the connection issues. Feel free to comment this article and I will update it if needed.
RDP & Windows 2008 R2
As RDP used TLS 1.0 out for the box you might lock out yourself from the Windows 2008 R2 server as KB 3080079 might be missing as documented by Microsoft here. Once installed this point should be covered.
The GUI and the GPO might still show TLS 1.0 this is a known bug as mentioned here.
Make also sure you are using Remote Desktop Protocol (RDP) 8.0 (or better 8.1 as outlined in KB KB2830477) on your Windows 7 PC as mentioned here.
https & Internet Explorer 10 / Internet Explorer 11
If you disable TLS 1.0 it might be you break any https connection towards the https website hosted on the Windows Server 2012 R2 / 2008 R2. No https website will be working when you use the Internet Explorer. However solving that one is quite easy. Simply enable TLS 1.1 and TLS 1.2 in the browser and you should be fine. Depending on your OS there is also no action needed per default (see below).
Windows 7 & Internet Explorer 11: TLS 1.1 and TLS 1.2 are enabled per default
Windows 8 & Internet Explorer 10: TLS 1.0 and TLS 1.2 are disabled per default
Windows 10 & Internet Explorer 11: TLS 1.1 and TLS 1.2 are enabled per default
You can control these settings via GPO or via Registry keys (The example below will enable TLS 1.0, 1.1 and 1.2 and disable SSL 2.0 and 3.0):
Windows Registry Editor Version 5.00[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"SecureProtocols"=dword:00000a80
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings]
"SecureProtocols"=dword:00000a80
3rd party application which used the SCHANNEL implementation in the Windows OS
Some 3rd party application (e.g. FTP Software) might use the build in SCHANNEL (aka Secure Channel) implementation in the Microsoft Windows OS. To ensure they can still connect to your Windows Server you need to enable TLS 1.1 and TLS 1.2 on the Windows OS where the 3rd party application is installed one. Enabling TLS 1.1 and TLS 1.2 is quite easy and can be done via the following registry key (as outlined here):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
After an OS reboot TLS 1.1 and TLS 1.2 would be accessible for clients. Keep noted that Windows Vista do not support TLS 1.1 or TLS 1.2 (as written here).
Microsoft Office running on Windows 7
You might think that enabling TLS 1.1 in the regestry as mentioned above would be enough for MS Office however that's not the case. Microsoft Office makes use of WinHTTP (Windows HTTP Services) which required some special settings. So for Windows 7 you need to do some additional tweaks (see here or here):
Windows 7 64bit OS:
2.) Add the following registry keys (to enable TLS 1.1 & TLS 1.2; and disable TLS 1.0):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000a00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000a00
3.) reboot the OS
Windows 7 32bit OS:
2.) Add the following registry keys (to enable TLS 1.1 & TLS 1.2):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000a00
3.) reboot the OS
Microsoft Office running on Windows 8.1 / 10
For Windows 8.1 or Windows 10 Microsoft already enabled TLS 1.1 and TLS 1.2 for WinHTTP-based applications by default. So you do not need to do any changes here.
Microsoft Office running on Windows Vista
Windows Vista do not support TLS 1.1 or TLS 1.2 (as written here) so you need to replace this OS fully.
Note:
While you are already improving the environment you should also replace the SHA1 SSL certificate used to one with SHA2.
Leave your comments
- Posting comment as a guest.
How to fix “The program can’t start because MSVCR110.dll is missing from your computer.” error on Windows
[RESOLVED] You do not have the permission to send the message on behalf of the specified user
[RESOLVED] Exchange 2013/2016 hub transport Mail.que file large in size
[RESOLVED] The Open Procedure for service XXX in DLL "C:\Windows\System32\XXX.dll" failed. Performance data for this service will not be available. The first four bytes (DWORD) of the Data section contains the error code
[RESOLVED] "The client and server cannot communicate, because they do not possess a common algorithm"