title: Could not establish secure channel for SSL/TLS for SOAP call
body: <p>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.</p>
  
  <p>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:</p>
  
  <pre><code>Unhandled Exception: System.ServiceModel.Security.SecurityNegotiationException:
  Could not establish secure channel for SSL/TLS with authority 'www.xyzzy.com'.
  ---&gt; 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)
  </code></pre>
  
  <p>The relevant piece of code would seem to be:</p>
  
  <pre><code>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)
  </code></pre>
  
  <p>From my personal laptop (WinXP), I can run the code and it connects to the new server without issues.</p>
  
  <p>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.</p>
  
  <p>After googling the issue I tried adding the following line (certainly not suitable for production but I wanted to test):</p>
  
  <pre><code>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
  </code></pre>
  
  <p>The result was the same.  The SSL error still occurred.</p>
  
  <p>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.</p>