Friday, February 4, 2011

How to specify accepted certificates for Client Authentication in .NET SslStream

I am attempting to use the .Net System.Security.SslStream class to process the server side of a SSL/TLS stream with client authentication.

To perform the handshake, I am using this code:

SslStream sslStream = new SslStream(innerStream, false, RemoteCertificateValidation, LocalCertificateSelectionCallback);
sslStream.AuthenticateAsServer(serverCertificate, true, SslProtocols.Default, false);

Unfortunately, this results in the SslStream transmitting a CertificateRequest containing the subjectnames of all certificates in my CryptoAPI Trusted Root Store.

I would like to be able to override this. It is not an option for me to require the user to install or remove certificates from the Trusted Root Store.

It looks like the SslStream uses SSPI/SecureChannel underneath, so if anyone knows how to do the equivalent with that API, that would be helpful, too.

Any ideas?

  • What the certificate validation is doing is validating all certificates in the chain. In order to truely do that it just contact the root store of each of those cerficates.

    If that's not something you want to happen you can deploy your own root store locally.

  • It is not the validation part I want to change. The problem is in the initial handshake, the server transmits the message informing the client that client authentication is required (that is the CertificateRequest message). As part of this message, the server sends the names of CAs that it will accept as issuers of the client certificate. It is that list which per default contains all the Trusted Roots in the store.

    But if is possible to override the certificate root store for a single application, that would probably fix the problem. Is that what you mean? And if so, how do I do that?

  • It does not look like this is currently possible using the .NET libraries.

    I solved it by using the Mono class library implementation of System.Security.SslStream, which gives better access to overriding the servers behavior during the handshake.

0 comments:

Post a Comment