Recently I had to call a Java web service from Wcf. The service was secured with a 256-bit ssl certificate. Every request I made was rejected with a 401 Unauthorized response.
I then used this site to check what encryption strength my machine supports:
It seemed my pc is configured to only allow 128 bit connection.
Luckily I have found this link which explains how to configure windows to use 256-bit Ssl (Vista only). It seems the problem is in the windows defaults and not in Wcf. This changed the result in IE:
and also the Wcf client worked. The strange is that the setting that needs to be changed should only affect the order of the supported algorithms. So if the server requires a 256-bit OR a 128-bit key, the default setting would suggest 128 first. But if the server only allows 256-bit I would expect this to work since this is a supported configuration, just not the first in order. Either way the fix made it work.
When you use SSL with WCF or .Net 2.0 web services you might get this exception:
This means that the X.509 certificate that the server presented is not valid according to your client's trust chain. the trust chain is the list of certificate issuers that you trust. In many cases this means you should not trust this web service. In some cases you decide to trust it anyway, due to the fact that you know the author or are still in early testing stages. You have two options:
Option 1 - Make the certificate valid You would need to have the server certificate or its issuer's certificate in the trusted certificates store of your client. This can be done using WinHttpCertCfg.exe or using the "mmc" console.
Option 2 - Configure WCF/.Net 2.0 to not validate the certificate With WCF, a common gotcha is to try and achieve that by setting:
However this will not work with transport level security (SSL) but only with message level security. The correct way to do it is the same one as with .Net 2.0 web services. Just add this code before calling the service: