Could not establish secure channel for SSL/TLS for SOAP call

Question

Our core server is calling out to a soap web service over https on a number of different servers to confirm that a transaction has completed.

The code is dotnet 3.5 (vb) and works for the various callback services we have set up until we just moved a new one into production and it is refusing to communicate, giving the following error:

Unhandled Exception: System.ServiceModel.Security.SecurityNegotiationException:
Could not establish secure channel for SSL/TLS with authority 'www.xyzzy.com'.
---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)

The relevant piece of code would seem to be:

Dim epAddr As New System.ServiceModel.EndpointAddress(sys.CallbackAddress)
Dim bind As New System.ServiceModel.BasicHttpBinding(ServiceModel.BasicHttpSecurityMode.Transport)

_svc = New CallbackSvc.XyzzyCallbackSoapClient(bind, epAddr)

From my personal laptop (WinXP), I can run the code and it connects to the new server without issues.

From the main server (which calls all the callback services) (Windows Server Enterprise Service Pack 1), the code always results in the aforementioned SSL error.

After googling the issue I tried adding the following line (certainly not suitable for production but I wanted to test):

System.Net.ServicePointManager.ServerCertificateValidationCallback = Function(se As Object, cert As System.Security.Cryptography.X509Certificates.X509Certificate, chain As System.Security.Cryptography.X509Certificates.X509Chain, sslerror As System.Net.Security.SslPolicyErrors) True

The result was the same. The SSL error still occurred.

Other places suggest the root cert has not be installed correctly on the calling machine but both the new server and old callback servers use certs issued by Go Daddy so I don't think this is the case here.

Answer 1

This turned out to be an interaction between the production "core" server (the one calling the service) and the destination server (hosting the service) not sharing an acceptable https algorithm. wfetch was extremely helpful in diagnosing the issue.

It turned out the destination server was not set up to accept TLS 1.0, only SSL 3.0 was accepted.

Apparently, something changed in Windows 2008 Server which means that outbound https connections would only be acceptable using TLS 1.0 (or better, presumably).

In our case, the problem was resolved when the configuration on the destination server was changed to accept TLS. It feels like there should be a way to alter my program to force it to use SSL but I haven't found it.