2

Since upgrading to .Net 4.6.1 I can no longer call a third party web service but get the error 'Could not establish secure channel for SSL/TLS with authority...'. I can workaround this in a couple of ways but I don't find these ways acceptable. a) Add the following line to the code:

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

This ensures I do not use Tls1.2 and all works as before with .Net 4.5.2

b) Add the following line to my config file

<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>

This ensures I do not use Tls1.2 and all works as before with .Net 4.5.2

I would rather be able to use Tls1.2 than turn it off for all calls from my application, my application communicates with many third party services and I don't want to limit all communication because of a problem with one.

Using WireShark to diagnose the problem has highlighted that the client certificate is not sent, which clearly leads to this error.

WireShark

<system.serviceModel>
<bindings>
    <basicHttpBinding>
        <binding name="def">
            <security mode="Transport">
                <transport clientCredentialType="Certificate"/>
            </security>
        </binding>
    </basicHttpBinding>
</bindings>
<client>

    <endpoint address="https://abc" binding="basicHttpBinding" bindingConfiguration="def" contract="ghi" name="jkl"/>
</client>

The ClientCertificate is set in code

I have read many articles on stackoverflow, the most similar / useful is listed below: How to force WCF client to send client certificate?

I have checked:

  1. Access to the client certificate (private key) is available
  2. The server certificate is trusted and valid
  3. The client certificate matches one of the specs the server sent

  4. Converted my binding to a custom binding to specify requireClientCertificate - no effect

    <endpoint address="https://abc" binding="customBinding" bindingConfiguration="def" contract="ghi" name="jkl"/>

Can anyone point me to anything else I can check or help me understand why my certificate is not sent?

Update 2nd June I can download the wsdl successfully using my client certificate to authenticate in Chrome but not in either Internet Explorer nor Edge!

I believe that Chrome doesn't use SChannel (as Edge and IE do) for TLS but it's own implementation of SSL/ TLS.

While I'm not 100% sure I'm currently considering that the problem is the server is specifying a signature algorithm for the client certificate that doesn't match the clients signature algorithm. I don't really know enough about how TLS 1.2 works to be sure but from a read of the spec tools.ietf.org/html/rfc5246#section-7.4.4 it seems possible.

See Certificate request in wireshark trace - i.stack.imgur.com/BwmUM.png and certificate details - i.stack.imgur.com/pbKEF.png

Any tls1.2 experts out there?

Community
  • 1
  • 1
Tim Hill
  • 21
  • 1
  • 5
  • One thing left to try. Specify the client certificate in endpoint behavior in configuration like [here](https://msdn.microsoft.com/en-us/library/ms731323(v=vs.110).aspx). – pepo Jun 01 '16 at 19:41
  • Thank you for your suggestion. I have just tried this, but unfortunately it's not made any difference. It still works if I disable Tls1.2 so I know my configuration changes are are correct. – Tim Hill Jun 02 '16 at 07:46
  • Are you sure you set rights to private key correctly? Try [this](http://stackoverflow.com/a/32605764/3245057). Or try to use the private key in code ie. in SignedCms. There is also CAPI event log (applications and services logs/microsoft/capi) that will log i.e. problems with validation of certificates but is is disabled by default so enable it. – pepo Jun 02 '16 at 10:15
  • pepo, thank you for some good suggestions. I have extracted the code to talk to the web service into a console app that I can run in Visual Studio and debug as it's a slow process getting to the position where I can test this quickly. As such I'm running the process as admin and am confident that I have access to the private key. The CAPI event log is interesting I've not come across this before, for anyone wanting to try this see [this link](https://blogs.msdn.microsoft.com/benjaminperkins/2013/09/30/enable-capi2-event-logging-to-troubleshoot-pki-and-ssl-certificate-issues/) – Tim Hill Jun 02 '16 at 19:59
  • I'm seeing a few errors validating the server certificate that might be worth following up, but I'm also seeing errors validating other server certificates including fe2.update.microsoft.com. The server certificate seems fine when I get the wsdl in Chrome. I'll spend a little time on this, but I also have some more info I'll update the question with. – Tim Hill Jun 02 '16 at 20:02

1 Answers1

0

Update: The company we are working with decided to turn off TLS1.2 as Internet Explorer and Edge couldn't authenticate to their website either when the browser supports TLS1.2. I'll put this down to service mis-configuration.

Tim Hill
  • 21
  • 1
  • 5