Logging Monitoring Failures in Aspnet with Mutual Tls

In ASP.NET applications that enforce mutual TLS (mTLS), logging and monitoring failures often arise from the interaction between encrypted transport, certificate-based client authentication, and telemetry pipelines. When mTLS is configured, the server validates client certificates during the TLS handshake, but application-layer logging may not capture the identity or context of the authenticated peer if the certificate details are not explicitly extracted and recorded.

Without explicit logging of the client certificate subject, thumbprint, or mapped user/role, security events appear as anonymous TLS connections. This creates blind spots for monitoring systems that rely on user or service identity to detect anomalies, such as unusual access patterns or privilege escalation attempts aligned with the OWASP API Top 10 category of Broken Object Level Authorization (BOLA).

Furthermore, logging failures can occur when errors during certificate validation are not captured with sufficient detail. For example, if an mTLS-enabled ASP.NET endpoint rejects a request due to an expired or untrusted client certificate, the resulting 400-level responses may be logged generically. Without the certificate validation error code or the distinguished name, operators cannot correlate failed handshakes with specific clients, complicating incident response and violating principles of effective security monitoring.

Another specific risk emerges when application telemetry omits the TLS session metadata while recording request-level metrics. Metrics such as request duration and status code may be collected, but without associating them to the client certificate identity, security operations teams lose the ability to profile normal behavior per peer. This gap can mask abuse scenarios where a compromised certificate is used to perform low-and-slow attacks that bypass rate limiting or evade detection through fragmented request patterns.

Finally, log data that omits cipher suite, negotiated protocol version, or certificate chain details can hinder forensic analysis. In regulated environments aligned with frameworks like PCI-DSS or SOC 2, the absence of these fields can impede compliance audits. Instrumenting ASP.NET to log mTLS metadata alongside application events ensures that detections for issues such as SSRF or unsafe consumption of user-supplied URLs remain meaningful and actionable.

Remediation centers on ensuring that the ASP.NET pipeline captures, validates, and logs mTLS metadata consistently. Below are concrete code examples using ASP.NET Core with Kestrel mTLS configured via configuration and middleware.

1. Configure mTLS in Program.cs

Set up HTTPS with client certificate validation so the server requests and validates client certificates.

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            httpsOptions.AllowAnyClientCertificate();
            // Optionally set revocation mode
            // httpsOptions.ClientCertificateRevocationCheckMode = CertificateRevocationMode.Online;
        });
    });
});

// Add services to the container.
builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

2. Middleware to extract and log certificate details

Inject a middleware that reads the client certificate and enriches the logging context with fields useful for monitoring and detection.

app.Use(async (context, next)
{
    var cert = context.Connection.ClientCertificate;
    if (cert != null)
    {
        var subject = cert.Subject;
        var thumbprint = cert.Thumbprint;
        var enhancedKeyUsage = string.Join(",", cert.Extensions.OfType<X509EnhancedKeyUsageExtension>()
            .SelectMany(e => e.EnhancedKeyUsages.OfType<Oid>())
            .Select(o => o.Value));

        using (logger.BeginScope(new Dictionary<string, object>
        {
            ["ClientCertificateSubject"] = subject,
            ["ClientCertificateThumbprint"] = thumbprint,
            ["ClientCertificateEKU"] = enhancedKeyUsage
        }))
        {
            await next(context);
        }
    }
    else
    {
        // Log missing client certificate as a security event
        logger.LogWarning("mTLS client certificate missing for request {Method} {Path}", context.Request.Method, context.Request.Path);
        await next(context);
    }
});

3. Structured logging with certificate metadata

Ensure log entries include certificate fields so monitoring systems can aggregate and alert on them. The example below uses a logger that supports structured data (e.g., Serilog with enrichment or an ILogger implementation that includes the scope).

// Example log event after middleware enrichment
// Properties captured:
// - Path: /api/v1/resource
// - ClientCertificateSubject: CN=service-account-prod, O=Example Corp, C=US
// - ClientCertificateThumbprint: A1B2C3D4E5F6...
// - RequestId: 
logger.LogInformation("Request completed {StatusCode} for {Path} with client {ClientCertSubject}",
    context.Response.StatusCode, context.Request.Path, 
    context.Items.TryGetValue("ClientCertificateSubject", out var subj) ? subj : "unknown");

4. Validation and error logging

Explicitly log certificate validation failures with details that help differentiate between configuration issues and potential attacks.

try
{
    // Force validation if not automatic
    var chain = new X509Chain();
    chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck; // adjust per policy
    bool isValid = chain.Build(cert);
    if (!isValid)
    {
        logger.LogWarning("mTLS certificate validation failed for subject {Subject}. Chain status: {Status}",
            cert.Subject, string.Join(",", chain.ChainStatus.Select(s => s.Status)));
    }
}
catch (CryptographicException cex)
{
    logger.LogError(cex, "Cryptographic error while validating client certificate");
}

5. Correlation with application identity

Map certificate fields to application identities (e.g., via a lookup table or directory service) and include that mapping in logs to support BOLA and inventory management checks.

string mapCertToUserId(X509Certificate2 clientCert)
{
    // Example: map by SAN or custom extension
    var sanExtension = clientCert.Extensions.OfType<SubjectAlternativeNameExtension>()?.FirstOrDefault();
    if (sanExtension != null)
    {
        foreach (var name in sanExtension.DnsNames)
        {
            if (name.StartsWith("user:", StringComparison.OrdinalIgnoreCase))
                return name.Substring(5);
        }
    }
    return null;
}