0

I am having an issue with a .NET Service Reference connection. We are moving from .NET v 4.5 to v 4.6.2. There is a change in the default SecurityProtocol.

v 4.5 uses SSL3 and TLS 1.0 by default, but v 4.6+ uses TLS 1.0, TLS 1.1, and TLS 1.2 by default.

When connecting to most services, SSL3 is disabled. The behavior seems to be that the highest SecurityProtocol it attempted first. If this fails, then the client usually moves down the chain to the next level.

For this particular server at the web service, it seems that if the first protocol is not the correct protocol, then it does not move down the list of specified protocols.

I've established that the service only supports TLS 1.0. No other protocol will connect.

Works (the default for v 4.5):

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls;

Also works (set custom in code):

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;

Fails:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Fails:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11

Fails:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Fails:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Unfortunately, it appears that the security protocols are specified at the app domain level. I have other services that we call out to that require TLS 1.2. This particular service only functions on TLS 1.0.

Does anyone have a solution that would either:

A) allow that service alone to use only TLS 1.0 while leaving the other SecurityProtocol values at the default for v 4.6.2 with TLS 1.0, 1.1 and 1.2 available,

or

B) suggesting what the admin who maintains the service might do to reconfigure the service's server to properly negotiate? The web service is a WCF .NET application as well, but the application code and server are not under my control.

Thanks!

UPDATE:

I have confirmed that the server and IIS which has this WCF on the server will load web pages over TLS 1.2.

A copy of the web service that is on a different server/IIS used for testing does not have this issue (though there could be some differences in test vs. live apps as I don't control them or know their code).

We are using the following binding to connect to the WCF. 

<basicHttpBinding>
        <binding name="ClientCertAuthBindingEndPoint" closeTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
          <security mode="Transport">
            <transport clientCredentialType="Certificate" />
          </security>
        </binding>
        <binding name="ClientCertAuthBindingEndPoint1" closeTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
          <security mode="Transport">
            <transport clientCredentialType="Certificate" />
          </security>
        </binding>
        <binding name="CmreServiceSoap">
          <security mode="Transport" />
        </binding>
      </basicHttpBinding>
John Fager
  • 452
  • 1
  • 4
  • 16
  • B) It can be 2008R2 on their side.. TLS may need to be enabled like described here: https://support.quovadisglobal.com/kb/a433/how-to-enable-tls-1_2-on-windows-server-2008-r2.aspx – Maxim Mar 29 '17 at 03:59
  • I would agree that enabling TLS 1.2 might resolve the issue, but TLS 1.0 is enabled and is part of the protocols that my client side should try. I've seen comments that servers can have security negotiation set differently so that it doesn't negotiate. I haven't been able to find any clear documentation on that though. – John Fager Mar 29 '17 at 14:18
  • TLS 1.2 is enabled on the server. It just doesn't seem to work on the WCF. – John Fager Mar 29 '17 at 16:46

0 Answers0