Allow skip chain validation in ClientCertificate authentication

[espenrl]

Background and Motivation

We use Microsoft.AspNetCore.Authentication.Certificate and for our use case chain validation gets in the way. We have the client certficate explicitly registered server side and validate that aspect in CertificateAuthenticationOptions.Events.OnCertificateValidated. Chain validation is really not needed as the client certificate is validated against a server side copy of the same certificate. If the chain validation fails we never get to doing our validation logic in OnCertificateValidated as the event is never raised.

NOTE: The ideal solution is to use either self signed certificates or certificates with valid chains. That is easier said than done when the same certificates are used across multiple environments.

Proposed API

public enum X509ChainTrustMode
{
    NoCheck
}

Usage Examples

void ConfigureCertificateAuthentication(CertificateAuthenticationOptions options)
{
    options.ChainTrustValidationMode = X509ChainTrustMode.NoCheck;
}

Risks

Additive API with opt in use. Should not result in any regression.

[espenrl]

I have to add that the inspiration for this design is long term usage of RavenDB.

From RavenDB documentation

https://ravendb.net/docs/article-page/5.0/csharp/server/security/overview

RavenDB does not use PKI infrastructure to trust certificates and uses a more strict approach. It will allow access to client certificates which are explicitly registered in the RavenDB server or certificates which have the same issuer and Public Key Pinning Hash as a certificate which is already trusted.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
See info in area-owners.md if you want to be subscribed.

[espenrl]

I am working on a library Extended client certificate authentication with management UI for ASP.NET Core, please see https://github.com/espenrl/erl.AspNetCore.Authentication.ClientCertificate. We're in the process of doing the final touches before a first release. This will give you an idea of the use case, as well as ready to run examples.

[espenrl]

I've got another idea. What about allowing a callback for configuring the X509Chain.ChainPolicy to our liking.

var chainPolicy = BuildChainPolicy(clientCertificate);

callback(chainPolicy);

var chain = new X509Chain
{
     ChainPolicy = chainPolicy
};

https://github.com/dotnet/aspnetcore/blob/master/src/Security/Authentication/Certificate/src/CertificateAuthenticationHandler.cs#L125-L129

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[bartonjs]

This seems to be either for SslStream or HttpClient (or both), changing area.

[karelz]

Triage: We believe this should be part of larger issue around certificate chains and their options -- there is already existing tracking issue - @wfurt will link it and close this one.

[wfurt]

may be in similar to #35839. We may want to expose some better control over validation in general.

[espenrl]

As I have understood it the client certificate goes through validation on SSL handshake as well as in CertificateAuthenticationHandler. I guess the public API will have to expose ways to relax validation of both.

[wfurt]

Client and server now have option to pass in X509ChainPolicy via CertificateChainPolicy in ssl options. If present, chain constructed inside SslStream will respect the setting. You can customize it anyway you want (including disabling AIA) but as far as I can tel there is no way to disable the validation completely. I don't know how the options would surface in Kestrel but @Tratcher can probably point you in right direction.