Could not establish secure channel for SSL/TLS with authority 'xxxxx.com'

Question

I'm trying to write a client against a customer's SOAP webservice, using VS2013 and WCF. The webservice itself is behind their firewall, so they've established a proxy that I'm trying to contact. (The proxy seems to be implemented using MuleSoft's ESB, which may or may not be relevant.)

I've been given an https: url, and a username/password. When I load the url into a browser, I'm prompted for the username/password, and then I see the .wsdl. The .wsdl specifies an internal url that I can't access, but I figure that's for the actual site.

When I create a Service Reference in VS2013, using the proxy URL, I'm prompted for the username/password three times, then I get a proper client, settings in app.config, etc.

The generated bindings in the app.config are for a basicHttpBinding with security mode Transport, and an endpoint address pointing to that inaccessible internal url.

So, from the generated bindings, I:

1. Replace the inaccessible internal url with the proxy url I've been given.

2. Change the security mode to "TransportWithMessageCredentials"

   <bindings>
       <basicHttpBinding>
           <binding name="MyCustomersServiceSoapBinding">
               <security mode="TransportWithMessageCredential" >
                   <message clientCredentialType="UserName" />
               </security>
           </binding>
           <binding name="MyCustomersServiceSoapBinding1" />
       </basicHttpBinding>
   </bindings>
   

3. Replace the ClientCredentials with username and password:

   using (var client = new MyCustomersServiceClient()) { var loginCredentials = new ClientCredentials(); loginCredentials.UserName.UserName = "ausername"; loginCredentials.UserName.Password = "apassword";

   var defaultCredentials = client.Endpoint.Behaviors.Find<ClientCredentials>();
   client.Endpoint.Behaviors.Remove(defaultCredentials);
   client.Endpoint.Behaviors.Add(loginCredentials);
   
   var myData = new MyData
   {
   };
   
   
   var result = client.receiveData(myData);
   

   }

When I run it, I get an exception:

Could not establish secure channel for SSL/TLS with authority 'xxxxx.com'.

Browsing around, most of what I find suggests problems with ssl certificates, but I'm not sure that makes sense. If that were the case, I'd expect to see issues when I view the .wsdl through the browser. And I thought that by removing the default client credentials, I'd be bypassing the certificate check. And I am seeing a few posts about more obscure problems that result in this same error message.

I've turned on SOAP message logging, but that's provided me with no information. It shows the failed outgoing message, but nothing of use.

So I've been looking at the traffic in Fiddler. I see two messages, an HTTP message to "Tunnel to" with Result 200, and an HTTPS message to the proxy url with Result 401.

At this point, I see two possibilities:

1. I need to install an SSL certificate, the way the error message would suggest, or
2. the problem is simply that I'm not providing the username/password to the service in a way that it understands, and it's rejecting my attempt to connect.

I'm leaning towards the latter. My problem? I know nothing about the system that's hosting the service. I'm passing username/password in what I thought was the usual mechanism for WCF, and it's not working.

So, finally, the questions:

• Have I misled myself, and I do need to be messing about with SSL certificates?
• If not, what do I do in WCF to pass a username/password to an HTTPS webservice, hosted by MuleSoft ESB? (Mule EE Core Extensions/3.5.1, if that helps).

Answer 1

Not sure if the issue I encountered shares the same cause as your issue, but just in case I can help someone with this, adding requireClientCertificate=true solved my problem:

<bindings>
  <customBinding>
    <binding name="bindingName">
      ...
      <httpsTransport requireClientCertificate="true"/>
    </binding>
  </customBinding>
</bindings>

I had the same error message, but the web service I'm consuming is over HTTPS and requires a SSL certificate as authentication.

Answer 2

Many endpoints have been disabling TLSV1.0 and TLSV1.1 recently

try:

CURL https://<<service host>> -v -TLSV1.0

and

CURL https://<<service host>> -v -TLSV1.2

For instance, https://www.comodo.com doesn't allow TLSV1.0 or TLSV1.1 but does allow TLSV1.2.