SslStream.AuthenticateAsServer with client certificates doesn't allow for ACCEPT

[tmds]

I am connecting to a server which has an invalid certificate, using HttpClientHandler (desktop) and WinHttpHandler (CoreCLR). This works fine.

// Desktop Framework
var handler = new HttpClientHandler();
ServicePointManager.ServerCertificateValidationCallback = // return true;

// CoreCLR
var handler = new WinHttpHandler();
handler.ServerCertificateValidationCallback += // return true

When I configure the server to accept client certificates (ssl handshake), but do not provide a client certificate. The HttpClientHandler works as before, but the WinHttpHandler throws a WinHttpException (ERROR_INTERNET_SECURE_FAILURE).

[davidsh]

I am connecting to a server which has an invalid certificate

Do you mean an invalid SERVER certificate, i.e. one that isn't trusted or perhaps expired etc.?

Also, does the server REQUIRE or just ACCEPT (not required) client ssl certificates?

Can you provide a copy of the server side code? We'll need that to investigate this.

[tmds]

The test case is in https://github.com/tmds/KestrelHttpServer/tree/client_certificate
kestrelhttpserver\test\microsoft.aspnet.server.kestreltests\httpsconnectionfiltertests.cs
AllowCertificateContinuesWhenNoCertificate

[tmds]

By invalid I mean: self signed, not expired
The server calls AuthenticateAsServerAsync with clientCertificateRequired set to true. The validation callback always returns true.

[davidsh]

So, the "server" is Kestrel which uses .NET SslStream to implement the server-side of the HTTPS connection for the Kestrel server. I assume the server is also using CoreFx/CoreClr?

And if the server REQUIRES client certificates and the client is not sending any, then getting an error back would be expected, wouldn't it? The default settings for WinHttpHandler client certificate selection is manual and it looks at the .ClientCertificates property to find the certs. And since that property by default is an empty collection, there are no certs.

[tmds]

It looks like on the coreclr, clientCertificateRequired means Required and on the desktop frame it means Accept.
If clientCertificateRequired really means required, there is no way to specify Accept. If it means Accept, Require can be implemented in the validation callback.
That is the way it is used today (e.g.: http://stackoverflow.com/questions/26930398/sslstream-authenticateasserver-with-optional-clientcertificate)

[davidsh]

Ok. So, this looks like a bug/app-compat-difference for System.Net.Security.SslStream API surface.

I wil re-title the bug and assign to the right people.

[davidsh]

@CIPop @pgavlin @SidharthNabar @bartonjs PTAL

[tmds]

Thanks @davidsh

[CIPop]

@tmds / @davidsh Please provide a smple repro project or FunctionalTest for this issue with SslStream in CoreFX.

[tmds]

@CIPop @davidsh This isn't an issue. I forgot to pass the handler to the HttpClient. On the desktop framework this didn't cause an issue because the validation was done by the ServicePointManager. Sorry for the inconvenience.

[CIPop]

Not a problem. Thanks for following-up @tmds!