Dangling Dns in Aspnet with Mutual Tls

A dangling DNS record in an ASP.NET application becomes a risk when mutual TLS (mTLS) is enforced for client authentication but the server’s host or service name resolves inconsistently. In mTLS, both server and client present certificates, and the server typically validates the client certificate and may also perform hostname verification against the certificate’s subject alternative names (SAN) or common name (CN). If a DNS name used in the server URL or in certificate SAN no longer points to a service that should be reachable, an attacker who can influence or observe the resolution path might redirect traffic to an unintended host or intercept attempts, especially when the client does not strictly validate the server identity.

In ASP.NET, when you configure mTLS via Kestrel or HttpClient, the framework can be set to require client certificates and to validate the server certificate. If the URL used to reach a backend service contains a dangling DNS name (for example, a name that resolves to a different environment or an abandoned infrastructure), the client may inadvertently connect to a server that presents a valid certificate for a different domain. Because the client may fail to check the name against the certificate or may rely on a cached or split-horizon DNS resolution, the mTLS protection does not fully prevent misrouting or impersonation. This is particularly relevant in microservice or hybrid cloud setups where DNS is managed separately from certificate issuance and rotation.

Consider an ASP.NET Core service that calls an internal API using a hostname like internal-api.example.com. If the DNS record for internal-api.example.com points to an old or unintended IP, and the server’s certificate still contains that name in its SAN, a client using mTLS with default or loosely configured validation might complete the TLS handshake but route traffic to the wrong host. The mTLS layer ensures encryption and client authentication, but it does not automatically prevent the client from trusting a server whose identity does not match the intended endpoint. This mismatch can expose workflows that rely on name-based routing, service discovery, or legacy configuration where DNS and certificates are not synchronized.

middleBrick detects such inconsistencies by scanning the unauthenticated attack surface and cross-referencing OpenAPI specifications with runtime observations. For example, if the spec defines a server URL with a hostname that does not align with certificate SANs observed during scans, middleBrick flags potential misconfigurations in authentication and identity validation. This helps teams identify dangling DNS scenarios where mTLS is present but not fully protective due to naming mismatches.

To reduce risk, ensure DNS records are authoritative and point only to intended services, and enforce strict server certificate validation that includes hostname verification. In ASP.NET, this means explicitly validating the server name in the certificate and avoiding fallback or lenient checks that might accept mismatched identities even when mTLS is in use.

Remediation focuses on strict certificate validation and hostname checks in ASP.NET. Use the built-in HTTPS configuration and HttpClient handlers to enforce mTLS and verify server identity. Below are concrete code examples for both Kestrel server setup and HttpClient usage.

Server-side (Kestrel) with mTLS in ASP.NET Core:

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            httpsOptions.ServerCertificate = new X509Certificate2("server.pfx", "password");
            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            // Optionally limit accepted client certificate issuers
            httpsOptions.ClientCertificateValidation = (cert, chain, errors) =>
            {
                if (errors != SslPolicyErrors.None) return false;
                // Additional custom validation, e.g., thumbprint or SAN checks
                return cert.Issuer.Contains("YourClientCA");
            };
        });
    });
});

var app = builder.Build();
app.MapGet("/", () => "Hello mTLS");
app.Run();

Client-side (HttpClient) with strict server certificate and hostname validation:

// Configure HttpClient to require and validate server certificate
var handler = new SocketsHttpHandler
{
    SslOptions = new SslClientAuthenticationOptions
    {
        ClientCertificates = new X509CertificateCollection { new X509Certificate2("client.pfx", "password") },
        RemoteCertificateValidationCallback = (message, cert2, chain, errors) =>
        {
            if (errors != SslPolicyErrors.None) return false;
            // Enforce hostname match
            if (!cert2.Subject.Contains("CN=api.example.com")) return false;
            // Optional: check SANs
            var eku = cert2.Extensions.OfType<X509EnhancedKeyUsageExtension>();
            // Add additional policy checks as needed
            return true;
        },
        // Explicitly set the target host for SNI and validation
        TargetHost = "api.example.com"
    },
    // Ensure the request uses HTTPS
};

using var client = new HttpClient(handler)
{
    BaseAddress = new Uri("https://api.example.com")
};

// Example call
var response = await client.GetAsync("/health");
response.EnsureSuccessStatusCode();

These examples ensure that mTLS is enforced with explicit certificate requirements and hostname verification, reducing the impact of dangling DNS by preventing connections to identities that do not match the expected name. Combine this with disciplined DNS management and certificate lifecycle processes to maintain alignment between naming and infrastructure.