Reputation: 1
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.
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
IE has the same problem until I disable TLSv1.2 in the advances properties. Firefox and Chrome both work.
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)
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.
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.
Could this be an issue on the remote server configuration or is it more likely that its a Windows/.Net Framework issue?
Why does IE and .Net Framework not respect the server preferred order?
Thank you very much in advance.
-Willey
Upvotes: 0
Views: 1698
Reputation: 86
According to your description I would guess that there is a problem during the TLS 1.2 handshake. A possible reason could be that at least one of the certs in the cert chain uses Md5 as it's hash algorithm.
If this is the case, you need to exchange that certificate by another one using an accepted hash algorithm.
Check the following links for further explanation:
Upvotes: 0