Periodically getting Could not create SSL/TLS secure channel RRS feed

  • Question

  • Hi,

    We have a windows service running on C# .net 4.7.2 on a Windows server 2008R2. The app periodically downloads an xml page hosted on an https web site. We have the following 2 line at at the startup of the application:

    ServicePointManager.Expect100Continue = true;
    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

    Recently (this didn't use to happen) we have started to see errors that happen almost every 2 to 3 times the xml file is downloaded. The error is:

    System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
       at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
       at IndjiWatch.Plugin.DataLoader.HttpDownloader2.HttpFileDownloader.ResponseCallback(IAsyncResult asyncResult) retrieving:

    As I mention the file is downloaded at least two times then it fails with the error, then it will download twice again, then it would fail again, and so for.

    Running the same binaries on a Windows 10 machine does not exhibit the same issue (it will always download), so seems to be something to do with Windows Server 2008R2, but I can seem to find out what it is.

    I have enabled the "Microsoft-Windows-CAPI2/Operational" log but there are no Error or Warning logs being registered there, that would explain any chain validation issues.

    Any ideas or suggestions?


    Thursday, June 13, 2019 12:07 PM

All replies

  • Do you know what version of SSL is actually being used by that server? It is all but unheard of that you'd enable all those protocols. Pretty much everybody only supports TLS 1.2. By specifying all those protocols you're telling the remote server you support them all which is a security hole. Your app should support only the latest version of SSL that your code can handle. For .NET 4.7.2 that would be TLS 1.2.  You can use Fiddler or similar tool to see what protocol is being selected during negotiation. Disable all the other ones.

    Server 2008 R2 does not have TLS 1.2 turned on by default IIRC. Use IISCrypto to get the list of allowed protocols and encryption algorithms. Make sure this lines up with your remote server requirements. It is possible that during negotiation one set of protocols is working but another isn't. This would lead me to believe the issue is on the server side but that is harder to verify.

    After you've configured your server to support TLS 1.2 and the required algorithms you should be able to remove the whole TLS configuration in your code. .NET 4.7.2 will use the OS defaults now so you don't need to explicitly allow anything. Then rerun your tests. If it still fails then use Fiddler or similar to see the SSL stuff go by and it should provide more insight into where the failure is.

    Michael Taylor

    Thursday, June 13, 2019 1:59 PM