C
combitz
Hi,
We have two identical Windows Server 2012 R2 boxes all up to date with security patches ("live" and "development testing")
We are running SQL Server 2016 Express and use the SQLCLR for some API calls. (not directly relevant to the problem but more for information on environment)
One of our API service providers has turned off support for TLS 1.0 and our connections now fail after the initial "hello". (Error: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.)
The main focus:
I can run the entire process on a WIN 10 machine and the API calls all work correctly using TLS 1.2 without me changing anything, (however even if we do set the ServicePointManager.SecurityProtocol to SecurityProtocolType.Tls12 the server is unable to obtain a crypto to communicate on)
What I've tried, and tested on the development box:
Using Wireshark
I've proven that the CLR calls from my WIN 10 machine are using TLS 1.2
I've proven that our development Windows Server 2012 R2 box is/was using TLS 1.0
So I disabled TLS 1.0 (via registry) and the next call attempts reverted to SSL 3.0 which is still not supported (I think we're going backwards here, I expected TLS 1.1 but not to be) So I disabled SSL 3.0 (via registry) and we started to get system schannel event errors as this topic is titled.
I've seen suggestions that the schannel issue is SSL 3.0 related but enabling SSL 3.0 is not really an option as we don't want to use it: Even if it does just clear up one of the many schannel errors: https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/event-id-36871-repeating-tls-error-10013/8cf22175-a443-40a9-a85f-a711efbac1d8?auth=1
I reverted my registry edits and tried a different approach: https://www.nartac.com/Products/IISCryptoOn the development box I ran IISCrypto and went through the process of disabling TLS 1.0 and SSL 3.0 testing along the way. The same results occurred as with my manual edits. I then tried enabling the "Best Practices" option: Now we are getting 8 schannel errors a second.
I tried another suggestion supplied in many forums, enabling FIPS:
1. In Control Panel, click Administrative Tools, and then double-click Local Security Policy.
2. In Local Security Settings, expand Local Policies, and then click Security Options.
3. Under Policy in the right pane, double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing, and then click Enabled.
4. Go to C:\ProgramData\Microsoft\Crypto\RSA and grant "Network Services" Read permission to "MachineKeys" folder.
Then restart server.
Still the schannel errors occur.
As a final option (I've pretty much lost the will to live at this point) I tried looking into other schannel issues and tried enabling "Allow local activation security check exemptions" Just in case it was an internal Cipher activation error
HPE Support document - HPE Support Center
I can't find any other support within Microsoft docs or any searches online that suggest anything else. We don't use MS Exchange which were listed in many posts. Both live and dev servers were initial server 2012 installs so no historic upgrade issues could be relevant and until I can find a solution to the dev box I don't want to apply any changes to the live system.
I'd really appreciate any help and advice as to where or what to try next to help identify why the development server will not use TLS 1.1 or 1.2 which according to Microsoft, should be enabled automatically.
Thanks in advance for any advice .
Stu.
Continue reading...
We have two identical Windows Server 2012 R2 boxes all up to date with security patches ("live" and "development testing")
We are running SQL Server 2016 Express and use the SQLCLR for some API calls. (not directly relevant to the problem but more for information on environment)
One of our API service providers has turned off support for TLS 1.0 and our connections now fail after the initial "hello". (Error: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.)
The main focus:
I can run the entire process on a WIN 10 machine and the API calls all work correctly using TLS 1.2 without me changing anything, (however even if we do set the ServicePointManager.SecurityProtocol to SecurityProtocolType.Tls12 the server is unable to obtain a crypto to communicate on)
What I've tried, and tested on the development box:
Using Wireshark
I've proven that the CLR calls from my WIN 10 machine are using TLS 1.2
I've proven that our development Windows Server 2012 R2 box is/was using TLS 1.0
So I disabled TLS 1.0 (via registry) and the next call attempts reverted to SSL 3.0 which is still not supported (I think we're going backwards here, I expected TLS 1.1 but not to be) So I disabled SSL 3.0 (via registry) and we started to get system schannel event errors as this topic is titled.
I've seen suggestions that the schannel issue is SSL 3.0 related but enabling SSL 3.0 is not really an option as we don't want to use it: Even if it does just clear up one of the many schannel errors: https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/event-id-36871-repeating-tls-error-10013/8cf22175-a443-40a9-a85f-a711efbac1d8?auth=1
I reverted my registry edits and tried a different approach: https://www.nartac.com/Products/IISCryptoOn the development box I ran IISCrypto and went through the process of disabling TLS 1.0 and SSL 3.0 testing along the way. The same results occurred as with my manual edits. I then tried enabling the "Best Practices" option: Now we are getting 8 schannel errors a second.
I tried another suggestion supplied in many forums, enabling FIPS:
1. In Control Panel, click Administrative Tools, and then double-click Local Security Policy.
2. In Local Security Settings, expand Local Policies, and then click Security Options.
3. Under Policy in the right pane, double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing, and then click Enabled.
4. Go to C:\ProgramData\Microsoft\Crypto\RSA and grant "Network Services" Read permission to "MachineKeys" folder.
Then restart server.
Still the schannel errors occur.
As a final option (I've pretty much lost the will to live at this point) I tried looking into other schannel issues and tried enabling "Allow local activation security check exemptions" Just in case it was an internal Cipher activation error
HPE Support document - HPE Support Center
I can't find any other support within Microsoft docs or any searches online that suggest anything else. We don't use MS Exchange which were listed in many posts. Both live and dev servers were initial server 2012 installs so no historic upgrade issues could be relevant and until I can find a solution to the dev box I don't want to apply any changes to the live system.
I'd really appreciate any help and advice as to where or what to try next to help identify why the development server will not use TLS 1.1 or 1.2 which according to Microsoft, should be enabled automatically.
Thanks in advance for any advice .
Stu.
Continue reading...