如何在具有传输安全性的WCF呼叫中使用自签名客户端证书？

Question

I have a WCF service (authored in-house) using a WS-HTTP binding and transport security (SSL). We are authenticating callers with client certificates and a whitelist of acceptable certificates (certs are provided to us out-of-band). So we're using a custom validator (eg a class deriving from System.IdentityModel.Selectors.X509CertificateValidator) to do a database query to check the whitelist.

It works in the following case: We have a root certificate used in development, issued by the development team (using OpenSSL). This root is trusted (eg installed in the Trusted Third-Party CA cert store) on the server hosting our WCF service. The test client is configured to present a certificate signed by this root. This case behaves as expected.

It does not work in the following case: The client presents a self-signed certificate to the service. In this case the client receives the error message "The HTTP request was forbidden with client authentication scheme 'Anonymous'", and-- here's the odd part-- the service's certificate validator doesn't even run. We don't get any chance to give the thumbs-up. The client cert is rejected by a layer lower than our validator.

How can I use a self-signed client certificate with my service?

Answer 1

You can't. In WCF, WS-HTTP transport security is SSL. My error results from a failure in the SSL negotiation between the parties.

The normal case of this negotiation is as follows: The service sends the client a list of root certificates that it trusts. The client examines this list and finds a certificate that the server will find trustworthy and sends it.

In my error case, the client is examining the server's list and determining that its cert will not be trusted. At this point the client will normally attempt to negotiate down to anonymous access, which is forbidden in my case, so the negotiation fails.

WCF does not support self-signed client certificates, or certs issued by an untrusted CA, in WS-HTTP binding + transport security scenarios, even if you use custom validation mode. It does support this scenario in message security. I suspect that Net.TCP supports this scenario, but haven't tested that.