Integrity Failures in Aspnet with Mutual Tls

In an ASP.NET application, enabling mutual TLS (mTLS) means the server requests and validates a client certificate in addition to presenting its own server certificate. When integrity controls are weak or misconfigured, this setup can expose vulnerabilities rather than eliminate them. Integrity failures occur when the application does not adequately verify the client certificate chain, thumbprint, or revocation status, allowing an attacker to present a fraudulent but technically valid certificate and be accepted as a legitimate client.

These failures are specific to the combination of ASP.NET and mTLS because the framework’s certificate validation hooks can be bypassed or incorrectly implemented. For example, if you only inspect the certificate subject or thumbprint without validating the full chain against trusted root authorities, an attacker who obtains or crafts a certificate signed by a trusted intermediate CA can bypass authentication. Similarly, if you skip revocation checks (online CRL or OCSP) and an attacker’s certificate has been revoked, the system may still treat it as valid.

Another common integrity issue arises from binding the certificate to the application logic incorrectly. In ASP.NET, developers sometimes use the client certificate to make authorization decisions (e.g., mapping a certificate thumbprint to a user or role) without additional integrity checks. If the mapping is not verified server-side on each request, or if the certificate data is assumed immutable after initial validation, tampering or confused deputy scenarios can occur. For instance, an attacker might present a certificate belonging to a low-privilege account but manipulate the authorization logic if role claims are derived from an untrusted source.

Real-world attack patterns like certificate spoofing or man-in-the-middle (when mTLS is not enforced end-to-end) map to OWASP API Security Top 10 controls such as broken object level authorization and insufficient encryption. In PCI-DSS and SOC2 contexts, failing to validate certificate chains and revocation can be a control gap. The scanner’s BOLA/IDOR and Authentication checks, combined with protocol-level analysis, can surface missing or weak certificate validation as a finding.

Using the middleBrick CLI, you can scan an ASP.NET endpoint that requires mTLS to surface such integrity issues: middlebrick scan https://api.example.com. The scan will flag weak certificate validation, missing chain verification, or missing revocation checks, and provide prioritized findings with severity levels and remediation guidance. For continuous assurance, the Pro plan enables scheduled scans and alerts if the API’s security score drops, while the GitHub Action can fail a build when risk thresholds are exceeded.

Remediation focuses on strict certificate validation, chain verification, and revocation checks in ASP.NET. Below are concrete code examples that demonstrate a robust mTLS setup.

1) Enforce client certificates and validate the full chain in Program.cs (ASP.NET Core):

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ConfigureHttpsDefaults(httpsOptions =>
    {
        httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
        httpsOptions.ClientCertificateValidation = (cert, chain, errors) =>
        {
            // Require chain to be valid and built
            if (errors != SslPolicyErrors.None) return false;
            // Optionally: enforce root or intermediate thumbprint
            var allowedRootThumbprint = "A1B2C3D4E5F6...";
            if (chain.ChainElements[^1].Certificate?.GetCertHashString() != allowedRootThumbprint)
                return false;
            // Check revocation (online CRL/OCSP)
            chain.ChainPolicy.RevocationMode = X509RevocationMode.Online;
            try { chain.Build(cert); }
            catch { return false; }
            return true;
        };
    });
});

This ensures the client certificate is validated against the chain, revocation is checked, and only certificates rooted at an allowed CA are accepted.

2) Additional authorization using certificate claims with integrity checks:

app.Use((context, next) =>
{
    var cert = context.Connection.ClientCertificate;
    if (cert == null) { context.Response.StatusCode = 403; return Task.CompletedTask; }
    // Validate thumbprint programmatically if needed
    var allowedThumbprint = "A1B2C3D4E5F6...";
    if (cert.Thumbprint?.Replace(" ", "") != allowedThumbprint)
    { context.Response.StatusCode = 403; return Task.CompletedTask; }
    // Map claims with integrity safeguards: avoid deriving roles from raw cert fields alone
    var roles = cert.GetCertHashString() is var certHash and not null
        ? MapCertHashToRoles(certHash) // server-side mapping, verified each request
        : [];
    context.Items["UserRoles"] = roles;
    return next();
});

3) Enforce mTLS across the stack and avoid insecure fallbacks:

<!-- In appsettings.json, prefer explicit settings -->
<Kestrel>
  <Endpoints>
    <Https>
      <ClientCertificateMode>RequireCertificate<ClientCertificateMode>
      <CertificateValidationMode>PeerTrust<CertificateValidationMode>
    </Https>
  </Endpoints>
</Kestrel>

By combining strict validation, revocation, and server-side role mapping, you reduce the risk of integrity failures. The middleBrick dashboard can track your API’s security score over time, and the MCP Server lets you scan APIs directly from your AI coding assistant to catch missing validation early.