I'm implementing mutual TLS (mTLS) between an ASP.Net Kestrel Web server hosted in an Azure API App (server) and IoT devices (clients). However, I need clarification on whether Azure API App Service or the Kestrel Web server automatically verifies that the client possesses the private key associated with its certificate.

Specifically, does the "Incoming client certificates" setting (Required/Optional) of the Azure API App or the setting "ClientCertificateMode" (RequireCertificate/AllowCertificate) of the Kestrel Web server have any effect on verifying private key possession?

My confusion stems from the fact that I couldn’t find answer to my question in the documentation of the Kestrel server, along with the following statement from the Microsoft documentation about the Azure API App:

"Your app code is responsible for validating the client certificate. App Service doesn't do anything with this client certificate other than forward it to your app."

Additional Context:

• Each IoT device has a unique client certificate signed by a root certificate stored in Azure Key Vault.

• The root certificate is used to issue client certificates during the manufacturing process.

• Each device securely stores its private key using TPM (Trusted Platform Module) to prevent key extraction.

• There is validation of the Client Certificate on Application Layer - we check if the "issuer" is the Root Certificate and we check the expiration of the certificate.

Sources:

• Configure TLS mutual authentication in Azure App Service

• Configure certificate authentication in ASP.NET Core

I'm implementing mutual TLS (mTLS) between an ASP.Net Kestrel Web server hosted in an Azure API App (server) and IoT devices (clients). However, I need clarification on whether Azure API App Service or the Kestrel Web server automatically verifies that the client possesses the private key associated with its certificate.

Specifically, does the "Incoming client certificates" setting (Required/Optional) of the Azure API App or the setting "ClientCertificateMode" (RequireCertificate/AllowCertificate) of the Kestrel Web server have any effect on verifying private key possession?

My confusion stems from the fact that I couldn’t find answer to my question in the documentation of the Kestrel server, along with the following statement from the Microsoft documentation about the Azure API App:

"Your app code is responsible for validating the client certificate. App Service doesn't do anything with this client certificate other than forward it to your app."

Additional Context:

• Each IoT device has a unique client certificate signed by a root certificate stored in Azure Key Vault.

• The root certificate is used to issue client certificates during the manufacturing process.

• Each device securely stores its private key using TPM (Trusted Platform Module) to prevent key extraction.

• There is validation of the Client Certificate on Application Layer - we check if the "issuer" is the Root Certificate and we check the expiration of the certificate.

Sources:

• Configure TLS mutual authentication in Azure App Service

• Configure certificate authentication in ASP.NET Core

• azure
• asp-core
• ssl
• azure-api-apps
• mtls

• Your app code is responsible for validating the client certificate --> this doesn't mean Azure APP service does nothing except forward the client certificate, it means the web server(App service) doesn't do application level validation. – Tiny Wang Commented Mar 25 at 14:00

2 Answers 2

Just like you know, the client will check whether the server certificate is issued by a trusted CA during TLS handshake. The client needs to look at the Issuer field in the certificate, check if the CA’s root certificate is in its trusted root store and verify the certificate's validity period (not expired), etc.

And mTLS adds a flow that the server also receives client certificate. The server(not the application) can be set to enforces requesting and requiring a client certificate, and helps to validate client’s private key possession/validity period/... in TLS layer. Your application can get involved after the TLS handshake succeeds, then perform additional application level validation, such as validate Issuer/Subject/your custom logic, for example

builder.Services.AddAuthentication(CertificateAuthenticationDefaults.AuthenticationScheme)
    .AddCertificate(options =>
    {
        options.AllowedCertificateTypes = CertificateTypes.All;
        options.Events = new CertificateAuthenticationEvents
        {
            OnCertificateValidated = context =>
            {
                var certificate = context.ClientCertificate;
                var rootCert = GetRootCertificate();
                var chain = new X509Chain();
                chain.ChainPolicy.ExtraStore.Add(rootCert); 
                chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;
                bool isChainValid = chain.Build(certificate);

                if (!isChainValid)
                {
                    context.Fail("Certificate chain validation failed.");
                    return Task.CompletedTask;
                }

                if (certificate.Issuer != "CN=YourRootCA")
                {
                    context.Fail("Certificate issuer validation failed.");
                    return Task.CompletedTask;
                }

                if (!IsDeviceAuthorized("deviceId"))
                {
                    context.Fail($"Device is not authorized.");
                    return Task.CompletedTask;
                }

                context.Success();
                return Task.CompletedTask;
            }
        };
    });

The posession of the private key matching the presented certificate is always checked by the TLS peer, i.e. the opposite TLS endpoint. This means for the TLS client checks that the server owns the private key for the presented server certificate, while the TLS server checks that the client owns the private key for the presented client certificate in case of mTLS. The proof of private key ownership is part of the TLS handshake.

But, it is not sufficient to only make sure that the private key matches the presented certificate. It is also crucial to check that the certificate is the expected one. Otherwise an impersonater or man in the middle attacker could just create their own self-signed certificate with their own private key. While this certificate validation is usually done by the TLS peer too during TLS handshake it can actually be done outside of the TLS handshake. It should of course be verified before any sensitive application data are exchanged, to make sure that these are only exchanged with the intended peer.

So it is possible for the TLS server to get the client certificate, make sure that the client has the matching private key but then give the extracted client certificate to the application or some upstream proxy for verification.