This will never work. All the wizards in the Dashboard are in .Net and need TLS 1.0 and 1.1.
Thank you for your exceptionally speedy response Mariette. I did find some additional regkeys to make .net use more secure channels. But I wasn’t sure if they were applicable. Making .net use TLS 1.2 won’t be of any use to me, no?
It requires a code update of the Essentials Dashboard and as that is closed source by Microsoft there is nothing you can do about this. It will not take long before the Essentials Dashboard stops working with Office 365 integration because Office 365 will require TLS 1.2 only. Integration in the dashboard will therefor stop working.
Thank you greatly for your time in helping me to understand.
Would you know if it’s just TLS 1.0/1.1 that WSE16 relies on. Could I go ahead and add SSL & RC4 regkeys to harden my box the best I can, or will doing so break core services too?
I found the addition of "SchUseStrongCrypto" to all .NET subkeys worked for me. My servers are currently supporting TLS 1.2 only. Refer to the following:
https://support.microsoft.com/en-us/help/4022913/how-to-resolve-azure-backup-agent-issues-when-disabling-tls-1-0-for-pc
Hope this helps!
Joe, thanks for this. Did you implement that on a Windows Server 2016 + Essentials Experience role? Or is it just Standard or Datacenter?
Thanks Joe. I had already read this information, and thought it may have been useful after learning here that the Dashboard is .net driven.
Have you tested connector wizards etc to ensure nothing else is broken?
Yes, I ran it on Windows Server 2016 Essentials up until lat week when I upgraded to Windows Server 2019 Standard with the added (unsupported but working) Essentials role. :-) Works in both.
I was reading about applying TLS conditions to specific domains this morning. However, after poking around it appears the information was only applicable to WSE2019
Adding SchUseStrongCrypto regkeys as directed in the link provided here did not work. The directions did not specify 32bit or 64bit DWORD entries, so I have used 32-bit. Do you think this would have made any difference?
The regkeys I am using to harden WSE16 are as follows:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000
Any ideas welcomed!
Did you add the "SchUseStrongCrypto" to registry on the Clients and Server? I found it is required on the Clients after disabling TLS 1.0 and 1.1 on the server.
A response to my Technet post seems to confirm what Mariette has already stated; it isn’t possible.
I have, however, been given a link to a workaround script: https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12
I will look into this after my WSE16 has finished restoring.
Thank you for your time. You're the best!
I only added the .net keys to the server. All of my clients are Win10, and I assumed they would use TLS 1.2 when necessary. I guess now that was wrong to assume.
On the other forum I was told that disabling TLS 1.0 will break other functions of the server. So, I’m inclined to review the mentioned script to harden my box.
If I am unhappy to proceed with the script for any reason, I will almost certainly come back to your solution Joe. With thanks!
I haven't found anything broken yet on my servers after disabling TLS 1.0 & 1.1 and adding the keys to the Servers and Clients. I can't vouch for that script as I have NOT tried it..... IMO I would try adding the keys to the clients first as it should be a quick and easy test; and easily reversed if it doesn't work for you. Good luck!
I didn’t find any reasons not to use the mentioned script, and every reason to use it. The script does need to be run on both server and clients. And, I found that it adds the SCHANNEL and .net regkeys which leads me to believe that Joe’s advice is sound.
But with that said, the script is most convenient, and addresses the other security issues too. For me, it was the perfect solution. Instead of various tasks spread across numerous notes, its everything I need in one place.
This has been an enlightening ride. I hope that the information in this thread helps others on the same path.
Many thanks!
So far so good with the script! Now to get it out to remote clients.
Your browser doesn't have Flash, Silverlight or HTML5 support.