CODEWITHSUNDEEP
c#web-serviceswcfssltcp
MikeZ
MikeZ

Reputation: 1355

WCF net.tcp SSL: none of the cipher suites supported by the client application are supported by the server

I have two PCs, let's call them PC1 and PC2.

I wrote a service-side application that opens a self-hosted WCF net.tcp endpoint, secured with an X509 certificate. The certificate I use for transport security is "Issued To" an arbitrary name, eg: MY-TEST-SERVICE.

I also wrote a client-side application to talk to the service. It knows and specifies the DnsIdentity that the service will provide (MY-TEST-SERVICE), it uses the same X509 certificate the service uses for transport security.

When I run the client on PC1, it works with the service on PC1 and PC2.

When I run the client on PC2, it works with the service on PC1 but the SSL handshake with the service on PC2 fails.

Turning on WCF client-side tracing on PC2, then connecting successfully to the secured net.tcp service on PC1 and failing to connect to the secured net.tcp service on PC2, I can see exactly which step is failing.

The trace for the successful handshake, from PC2 to PC1, reports: - Identity was determined for an endpoint reference - Identity verification succeeded

The trace for the failed handshake, from PC2 to PC2, reports: - The socket connection was aborted. This could be caused by... - Throwing an exception

Why would the identity verification process fail, but only when the client and service are both executing on PC2?

Upvotes: 4

Views: 1938

Answers (2)

developer82
developer82

Reputation: 13733

We eventually found the problem (I don't know if it applies to your exact case) without changing anything in our code - in our case it just started one day without any code change.

We found that a Windows Update has occurred that installed kb3102467 - which is .NET Framework 4.6.1, which we will eventually use, and probably will find itself on everyone’s machine.

It seems that the problem is that SHA512 is no longer supported in TLS 1.2 since it caused high CPU usage. We will probably need to issue new SSL certificates for both the client and the server.

As a workaround, we disabled TLS 1.2:

  1. Start regedit and browse to the following location: HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Protocols
  2. Create the following Key under Protocol: TLS 1.2
  3. Create the following two Keys under TLS 1.2: Client and Server
  4. Create the following DWORDs under both the Client and Server Key: DisabledByDefault and Enabled
  5. Under both Client and Server set the following: DisabledByDefault=1 and Enabled =0
  6. Reboot the server.

This fixed our problem while still having .NET F/W 4.6.1 installed on the machine.

Upvotes: 2

MikeZ
MikeZ

Reputation: 1355

Changing the SecurityMode on client and service from Transport to Message has resolved the original problem and all clients now work with all services.

This doesn't make sense to me, but regardless, I have a solution.

Upvotes: 0

Related Questions