Vulnerable Components in Aspnet with Mutual Tls

Mutual Transport Layer Security (mTLS) in ASP.NET requires both the client and server to present and validate X.509 certificates. When implemented incorrectly, this setup can introduce specific vulnerabilities that stem from certificate validation gaps and insecure application protocols. These misconfigurations can expose sensitive data or allow unauthorized access even when mTLS is in place.

One common vulnerability arises from improper certificate validation in the server-side callback. If the server does not enforce strict chain validation, revocation checks, or hostname verification, an attacker could present a valid but untrusted certificate and be accepted by the server. This bypasses the intended identity assurance of mTLS. For example, setting RemoteCertificateValidationCallback to always return true effectively disables the security provided by mTLS.

Another issue involves weak certificate policies on the client side. ASP.NET clients making outbound calls to backend services must be configured with a client certificate that is valid and trusted by the server. If the client uses a certificate with a weak key size or relies on a certificate store that is improperly secured, the integrity of the mTLS channel is weakened. Additionally, failing to set the correct ClientCertificates collection on HttpClientHandler results in the client not presenting a certificate, causing the server to reject the connection or fall back to less secure behavior.

Protocol-level weaknesses also contribute to risk. mTLS relies on TLS versions and cipher suites that must be explicitly restricted to strong options. Using older protocols such as TLS 1.0 or weak ciphers exposes the channel to downgrade attacks or decryption. In ASP.NET, the system default security settings may allow insecure protocols unless explicitly constrained via configuration or code. Similarly, certificate revocation checks may be skipped if the server or client is not configured to verify revocation, enabling the use of compromised certificates.

In the context of API design, an mTLS-protected endpoint may still be vulnerable if the application does not correlate certificate claims with application-level identities. For instance, a server might validate a client certificate but then rely on a claim or header that can be tampered with. This gap can lead to authorization issues where identity is assumed from the certificate but not verified against business rules. The server must map certificate properties, such as subject or SAN entries, to application roles or permissions explicitly and securely.

These issues are detectable by middleBrick’s unauthenticated scans, which analyze the attack surface without credentials. The scanner can identify weak validation logic, missing revocation checks, and insecure protocol settings through handshake analysis and negotiated parameters. By correlating these findings with the OpenAPI specification, including $ref-resolved definitions, middleBrick highlights inconsistencies between documented security expectations and runtime behavior in the mTLS flow.

Remediation focuses on enforcing strict validation, using strong protocols, and correctly configuring both client and server components. Below are concrete code examples that demonstrate secure mTLS setups in ASP.NET.

Server-side validation with strict certificate policies

Configure Kestrel to require client certificates and enforce validation in Program.cs:

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            httpsOptions.ServerCertificate = new X509Certificate2("server.pfx", "password");
            httpsOptions.ClientCertificateValidation = (cert, chain, errors) =>
            {
                if (errors != SslPolicyErrors.None)
                {
                    return false;
                }
                // Validate revocation
                chain.ChainPolicy.RevocationMode = X509RevocationMode.Online;
                // Enforce chain and policy constraints
                chain.ChainPolicy.VerificationFlags = X509VerificationFlags.NoFlag;
                chain.ChainPolicy.VerificationTime = DateTime.Now;
                chain.ChainPolicy.UrlRetrievalTimeout = new TimeSpan(0, 0, 30);
                bool isValid = chain.Build(cert);
                // Optionally validate subject or SAN here
                return isValid;
            };
        });
    });
});

This ensures the server requires a client certificate and validates the full chain, revocation, and constraints before accepting the connection.

Client configuration with explicit certificate and protocol restrictions

When the client initiates requests to an mTLS-protected endpoint, configure the HttpClientHandler to present the correct certificate and limit protocols:

var handler = new HttpClientHandler();
handler.ClientCertificates.Add(new X509Certificate2("client.pfx", "password"));
handler.SslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13;
handler.CheckCertificateRevocationList = true;
var client = new HttpClient(handler);
var response = await client.GetAsync("https://api.example.com/secure");

This approach explicitly sets strong protocols, enables revocation checking, and ensures the client certificate is included in the TLS handshake.

Mapping certificate claims to application identity

After validating the certificate, map its properties to your authorization model rather than relying on mutable headers:

app.Use(async (context, next) =>
{
    var cert = context.Connection.ClientCertificate;
    if (cert != null)
    {
        var subject = cert.Subject;
        // Extract CN or SAN and map to application roles
        // Do not trust incoming headers for identity decisions
        context.Items["ClientSubject"] = subject;
    }
    await next();
});

By deriving identity from the certificate directly, the application avoids authorization bypasses that could occur if relying on client-supplied claims.

middleBrick’s GitHub Action can be added to CI/CD pipelines to automatically verify that these configurations remain in place and that no regressions introduce weaker validation or protocol settings.