mTLS intermediate certificate handling for application that is both server and client

[hlinkaintenscz]

Due to specification, we have application, which is a node in a system where all nodes can communicate with each other, and each node can be both client and server.

The communication requires mTLS and the certificate chain is 3 levels deep. CA is shared, but each node has its own subCA and leaf certificate. Each node has to provide leaf and intermediate (subCA) when communicating with the other side. The last requirement causes the headache.

When configuring server part, we can specify the chain easily (according to docs, ServerCertificateChain should not contain the leaf):

public static void ConfigureMutualTlsServer(this ListenOptions listenOptions, MutualTlsOptions mTlsOptions)
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            var serverCert = mTlsOptions.GetLeafCert();
            var caCert = mTlsOptions.GetCaCert();
            var intermediateCert = mTlsOptions.GetIntermediateCert();

            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            httpsOptions.ServerCertificate = serverCert;
            httpsOptions.ServerCertificateChain = [intermediateCert];
            httpsOptions.CheckCertificateRevocation = false;
            httpsOptions.ClientCertificateValidation = (cert, chain, _) => cert.Validate(caCert, chain);
            httpsOptions.SslProtocols = SslProtocols.None;
        });
    }

the code above correctly sends both server cert and intermediate to the client.

The problem is that in order to include the intermediate certificate on the client's side, the only working option I found is to add the certificate to X509Store and the system will pick it up:

public static HttpMessageHandler ConfigureMutualTlsClient(this IServiceProvider _, MutualTlsOptions mTlsOptions)
    {
        var clientCert = mTlsOptions.GetLeafCert();

        var caCert = mTlsOptions.GetCaCert();
        
        RegisterIntermediateCertForClientAuth(mTlsOptions);

        var handler = new HttpClientHandler();
        handler.ClientCertificates.Add(clientCert);
        handler.CheckCertificateRevocationList = false;
        handler.ClientCertificateOptions = ClientCertificateOption.Manual;
        handler.ServerCertificateCustomValidationCallback = (_, cert, chain, _) => cert.Validate(caCert, chain);
        handler.SslProtocols = SslProtocols.None;
        return handler;
    }

private static void RegisterIntermediateCertForClientAuth(MutualTlsOptions mTlsOptions)
    {
        if (mTlsOptions.IntermediateCertFileName == null)
            return;

        var certPath = Path.Combine(mTlsOptions.IntermediateCertPath!, mTlsOptions.IntermediateCertFileName);
        if (!File.Exists(certPath))
            throw new FileNotFoundException("Intermediate cert file not found", certPath);

        var intermediateCert = new X509Certificate2(certPath);
        using var intermediateStore = new X509Store(StoreName.CertificateAuthority, StoreLocation.CurrentUser);
        intermediateStore.Open(OpenFlags.ReadWrite);

        var foundIntermediateCerts = intermediateStore.Certificates
            .Find(X509FindType.FindByThumbprint, intermediateCert.Thumbprint, validOnly: false);
        if (foundIntermediateCerts.Count == 0)
            intermediateStore.Add(intermediateCert);
    }

The problem is that placing the certificate into the store will affect the server side as well, causing httpsOptions.ServerCertificateChain = [intermediateCert!]; to be ignored and the server will end up sending the certificate found in the store.

Please note instances of MutualTlsOptions in client and server side are different objects, leading to different certificates. The application runs on .NET 8.0 on linux

#47680 (comment) was used as hint when trying to make the client send intermediate cert
#55368 another similar case, also suggesting that using intermediate store is the only way for client
however, both solutions also affect the server side of the application

[dotnet-policy-service]

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

[wfurt]

What is the platform? Linux or Windows? On Windows, the intermediate certs needs to be in the sore .... somehow.
Try to use SocketsHttpHandler's SocketsHttpHandler.SslOptions

Starting in .NET 8, it has SslClientAuthenticationOptions.ClientCertificateContext and it can be created with intermediate certs. That still adds them to store as needed but at least you should not need to deal with it explicitly...

[hlinkaintenscz]

Thank you Tomas for taking time to answer.

I tested it on Windows machine, but the application itself is running inside Linux Docker container.

The ClientCertificateContext helped and now both client and server side of the application send the correct intermediates! I spent days on this, but found literally zero content dealing with this very issue.

Thank you again for your help.

Below is the updated version of code that correctly attaches intermediates (if present) for both client and server side in case anyone else ever needs it (ignore the SslProtocols.Tls13 setting, as this is specific to our use case):

public static HttpMessageHandler ConfigureMutualTlsClient(this IServiceProvider _, MutualTlsOptions mTlsOptions)
    {
        var caCert = mTlsOptions.GetCaCert();

        var clientCert = mTlsOptions.GetLeafCert();
        var intCert = mTlsOptions.GetIntermediateCert();
        var additionalCerts = intCert is not null ? new X509Certificate2Collection(intCert) : null;

        var handler = new SocketsHttpHandler
        {
            SslOptions = new SslClientAuthenticationOptions
            {
                ClientCertificateContext = SslStreamCertificateContext.Create(clientCert, additionalCerts, true),
                CertificateRevocationCheckMode = X509RevocationMode.NoCheck,
                EnabledSslProtocols = SslProtocols.Tls13,
                RemoteCertificateValidationCallback = (_, cert, chain, _) => cert.Validate(caCert, chain)
            }
        };
        return handler;
    }

public static void ConfigureMutualTlsServer(this ListenOptions listenOptions, MutualTlsOptions mTlsOptions)
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            var caCert = mTlsOptions.GetCaCert();

            var serverCert = mTlsOptions.GetLeafCert();
            var intermediateCert = mTlsOptions.GetIntermediateCert();
            if (intermediateCert != null)
                httpsOptions.ServerCertificateChain = [intermediateCert];

            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            httpsOptions.ServerCertificate = serverCert;
            httpsOptions.CheckCertificateRevocation = false;
            httpsOptions.ClientCertificateValidation = (cert, chain, _) => cert.Validate(caCert, chain);
            httpsOptions.SslProtocols = SslProtocols.Tls13;
        });
    }

public static bool Validate(this X509Certificate? cert, X509Certificate caCert, X509Chain? chain = null)
    {
        if (cert == null)
            return false;

        var cert2 = cert as X509Certificate2 ?? new X509Certificate2(cert);
        var caCert2 = caCert as X509Certificate2 ?? new X509Certificate2(caCert);

        var customChain = new X509Chain();
        customChain.ChainPolicy.CustomTrustStore.Add(caCert2);
        customChain.ChainPolicy.TrustMode = X509ChainTrustMode.CustomRootTrust;
        customChain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;

        if (chain == null)
            return customChain.Build(cert2);

        foreach (var element in chain.ChainElements)
        {
            var elementCert = element.Certificate;
            if (!elementCert.Equals(caCert2) && !elementCert.Equals(cert2))
                customChain.ChainPolicy.ExtraStore.Add(element.Certificate);
        }

        return customChain.Build(cert2);
    }

[wfurt]

I'm glad you got it working. There is little bit of explanation here https://learn.microsoft.com/en-us/dotnet/core/extensions/sslstream-best-practices but it does not quite outline the benefit you were looking for.

Maybe we can add note for client side as well @rzikm and @liveans ? And either close this issue or change to documentation improvement.