title: Client certificate is not sent by .Net App using TLS1.2
body: <p>I'm having a .NET C# application which connects to a remote soap web service using 2-way SSL (client certificate) to authenticate. The application is running on IIS 7.5 on a Windows Server 2008 R2 system. Internet Explorer 11 is installed. </p>
  
  <p>Since the following registry key was set by our IT department the remote server returns an error stating that our client does not present a certificate.
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
  "SchUseStrongCrypto"=dword:00000001</p>
  
  <p>IE has the same problem until I disable TLSv1.2 in the advances properties. Firefox and Chrome both work.</p>
  
  <p>The remote server-preferred order of suites is configured as follows:
  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
  TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)</p>
  
  <p>I made a wireshark trace to see what cipher suites the browsers and the .NET app negotiate with the server. It looks like the .NET app and also IE with TLSv1.2 activated negotiate TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, while firefox and chrome negotiate TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.</p>
  
  <p>Does anyone has an idea why the 2-way ssl handshake works with the suite firefox and chrome uses but not with the suite IE and the .Net app uses.</p>
  
  <p>Could this be an issue on the remote server configuration or is it more likely that its a Windows/.Net Framework issue?</p>
  
  <p>Why does IE and .Net Framework not respect the server preferred order?</p>
  
  <p>Thank you very much in advance.</p>
  
  <p>-Willey</p>