Why Does My SSL Certificate Show as Untrusted in .NET (October 2026) Guide

Your SSL certificate shows as untrusted in .NET because the runtime cannot verify the server certificate against its trusted root certificate store. When .NET makes an HTTPS request using HttpClient or HttpWebRequest, it validates the server’s certificate chain, expiration date, hostname match, and revocation status. If any of those checks fail, .NET throws an AuthenticationException with the message “The remote certificate is invalid according to the validation procedure.”

This is one of the most frustrating errors .NET developers encounter, and the StackOverflow thread on this topic has over 382,000 views. I have hit this error across multiple projects, from local development with self-signed certificates to production deployments using private CAs, and the root cause is different every time.

The confusing part is that your browser often shows the same site as perfectly secure. Browsers have their own certificate stores and may accept certificates that .NET rejects, especially self-signed development certificates or certificates from internal PKIs. .NET uses the operating system’s certificate store (on Windows) or its own trust handling (on Linux/macOS), and the validation behavior differs across .NET Framework, .NET Core, and .NET 6+.

In this guide, I will walk you through every root cause, show you the exact error messages and what they mean, provide working code solutions for each .NET version, and give you a troubleshooting checklist so you can pinpoint your specific problem fast.

What Causes an SSL Certificate to Show as Untrusted in .NET

SSL certificate untrusted errors in .NET stem from seven common root causes. Each produces a slightly different error variant, and knowing which one you are dealing with determines the fix.

1. Self-Signed Certificates in Development

Self-signed certificates are the most common trigger. When you spin up a local API with HTTPS using dotnet dev-certs or a tool like mkcert, the certificate is not issued by a publicly trusted Certificate Authority. .NET sees it as untrusted because the signing key does not chain to a root CA in the system trust store.

Browsers let you click through a warning. .NET does not. The runtime throws immediately.

2. Missing Intermediate Certificates

If the server does not send the full certificate chain, .NET cannot build the trust path from the leaf certificate to the root CA. This happens when an IIS or Nginx server is configured to send only the leaf certificate instead of the full chain including intermediates.

I have seen this catch teams off guard because some browsers cache intermediate certificates from previous visits. .NET does not, so the same site works in Chrome but fails in HttpClient.

3. Expired Certificates

Certificates have a validity window defined by NotBefore and NotAfter fields. If the current date falls outside that window, the X509Chain build fails with NotTimeValid. This is straightforward to diagnose but easy to miss when a certificate expires silently in production.

4. Hostname Mismatch

The certificate’s Subject Alternative Name (SAN) or Common Name (CN) must match the hostname you are connecting to. If you connect to api.example.com but the certificate was issued for example.com, .NET rejects it with RemoteCertificateNameMismatch.

This commonly happens when developers connect to an IP address instead of a hostname, or when a wildcard certificate does not cover the specific subdomain being accessed.

5. Untrusted Root CA (Private CA)

Enterprise environments often use a private Certificate Authority to issue internal certificates. If the private root CA is not installed in the system trust store that .NET uses, every certificate it signs will fail validation. This is different from a self-signed certificate because the chain is valid, just not trusted by the OS.

6. Revoked Certificates

If a certificate has been revoked by its CA (due to compromise, rotation, or other reasons), .NET’s revocation check will fail. This is controlled by the X509RevocationMode setting. Online revocation checks can also fail if the OCSP responder is unreachable, causing false negatives.

7. TLS Version Mismatch

If the server only supports TLS 1.0 or SSL 3.0 and .NET defaults to TLS 1.2 or higher, the handshake fails before certificate validation even begins. This manifests differently from a trust error but is often confused with one. On .NET Framework 4.5 and earlier, the default TLS version may not include TLS 1.2.

Understanding the Error Messages

The error message .NET throws when SSL validation fails is intentionally generic: “The remote certificate is invalid according to the validation procedure.” This tells you that validation failed but gives zero detail about why. You need to dig into the SslPolicyErrors flags and X509Chain status to find the actual cause.

SslPolicyErrors Flags Reference

When a custom validation callback fires, it receives a SslPolicyErrors enum. Here is what each flag means:

None (value 0): No errors detected. The certificate passed all checks. If you still get an exception, the issue is elsewhere.

RemoteCertificateChainErrors (value 1): The certificate chain could not be built to a trusted root. This covers missing intermediates, untrusted roots, and self-signed certificates. Inspect chain.ChainStatus for details.

RemoteCertificateNameMismatch (value 2): The hostname does not match the certificate. Check the SAN entries and the URL you are connecting to.

RemoteCertificateNotAvailable (value 4): No certificate was provided by the server. This usually indicates a server-side configuration problem, not a client-side trust issue.

X509Chain Status Flags

When SslPolicyErrors includes RemoteCertificateChainErrors, the X509Chain object’s ChainStatus array tells you the specific problem:

UntrustedRoot: The chain terminates at a root certificate that is not in the trusted root store. This is the signature of self-signed or private-CA certificates.

PartialChain: The chain cannot be built to a root because intermediate certificates are missing. The server needs to send the full chain.

NotTimeValid: The certificate is expired or not yet valid. Check the validity dates.

NotTimeNested: The validity period of a certificate in the chain is not nested within the validity period of its issuer.

Revoked: The certificate has been revoked by the issuing CA.

CtlNotTimeValid: The certificate trust list is not valid at the current time.

The Cryptic Exception Problem

The root frustration is that the standard exception does not surface any of this detail. You see “The remote certificate is invalid according to the validation procedure” and nothing else. To get the actual chain status, you need to implement a custom validation callback that logs chain.ChainStatus, or use a diagnostic tool (covered in the troubleshooting section below).

This is why so many developers end up on StackOverflow. The error gives no direction, and you cannot fix what you cannot see.

Solution 1: ServerCertificateCustomValidationCallback (Modern .NET)

The recommended approach for .NET Core, .NET 5, .NET 6, .NET 7, and .NET 8 is to use HttpClientHandler.ServerCertificateCustomValidationCallback. This gives you per-handler control over certificate validation, meaning you can apply it to specific HttpClient instances rather than globally.

Here is the basic pattern for bypassing all certificate validation on a single HttpClient instance:

var handler = new HttpClientHandler();

handler.ServerCertificateCustomValidationCallback = (requestMessage, certificate, chain, errors) => true;

var client = new HttpClient(handler);

var response = await client.GetAsync("https://localhost:5001/api/data");

This callback receives the HTTP request message, the server certificate, the X509Chain object, and the SslPolicyErrors flags. Returning true bypasses all validation for this handler only.

Using SocketsHttpHandler Directly

In .NET 5 and later, SocketsHttpHandler is the default underlying handler. You can configure SSL validation directly on it:

var handler = new SocketsHttpHandler();

handler.SslOptions.RemoteCertificateValidationCallback = (sender, certificate, chain, errors) => true;

var client = new HttpClient(handler);

DangerousAcceptAnyServerCertificateValidator

For quick-and-dirty bypass, .NET Core 2.1 and later provides a shorthand property:

var handler = new HttpClientHandler();

handler.ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var client = new HttpClient(handler);

The intentionally scary name is a signal from the .NET team that this disables a critical security feature. Use it only in development.

Per-Handler vs Global Scope

The key advantage of ServerCertificateCustomValidationCallback over ServicePointManager is scope. The callback is attached to a specific handler, so it only affects HttpClient instances created with that handler. Other HttpClient instances in the same app continue to validate certificates normally.

This is the pattern I recommend for all modern .NET projects. It avoids the global state problems of older approaches and lets you control exactly which connections skip validation.

Solution 2: ServicePointManager (.NET Framework Legacy)

If you are working on a legacy .NET Framework 4.x application, ServicePointManager is the approach you will see in most older StackOverflow answers. It sets a global certificate validation callback that applies to all HTTP requests in the application domain.

Here is the standard code pattern:

System.Net.ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;

This must be set before any HTTP request is made. Once set, it applies to every HttpWebRequest and HttpClient call in the process.

App.config Alternative

Rick Strahl documented an approach that uses app.config or web.config to disable certificate checking without code changes:

<system.net>

<settings>

<servicePointManager checkCertificateName="false" checkCertificateRevocationList="false" />

</settings>

</system.net>

This only disables name checking and revocation list checking, not full chain validation. It is less risky than the callback approach but still reduces security.

Why ServicePointManager Does NOT Work in .NET Core

This is one of the biggest pain points developers discover when migrating from .NET Framework to .NET Core. The ServicePointManager.ServerCertificateValidationCallback property exists in .NET Core but silently does nothing for HttpClient.

The reason is architectural. In .NET Core, HttpClient no longer uses ServicePointManager for connection management. The underlying HTTP stack changed completely. ServicePointManager was retained for backward compatibility in some scenarios but does not intercept the modern HttpClient pipeline.

If you are on .NET Core or later and your ServicePointManager callback is not firing, this is why. Switch to HttpClientHandler.ServerCertificateCustomValidationCallback instead.

The Global Scope Problem

Even in .NET Framework where it works, ServicePointManager sets a global callback. Every outbound HTTPS request in your application bypasses validation. If your app talks to both internal services (with self-signed certificates) and external APIs (with public certificates), you are disabling validation for the external calls too.

This is a real security risk. An attacker performing a man-in-the-middle attack on any HTTPS endpoint your app connects to would go undetected because the callback returns true for all certificates.

Solution 3: HttpClientFactory with DI (ASP.NET Core)

For ASP.NET Core applications using dependency injection, the cleanest approach is to configure certificate validation per named or typed client through HttpClientFactory. This gives you per-service control and integrates with the DI container.

Here is how to register an HttpClient with SSL validation bypass in Program.cs or Startup.cs:

builder.Services.AddHttpClient("InternalApi", client =>

{

client.BaseAddress = new Uri("https://internal-api.local:5001/");

})

.ConfigurePrimaryHttpMessageHandler(() =>

{

var handler = new HttpClientHandler();

handler.ServerCertificateCustomValidationCallback = (msg, cert, chain, errors) => true;

return handler;

});

You then resolve the named client in your service:

public class MyService

{

private readonly HttpClient _client;

public MyService(IHttpClientFactory factory)

{

_client = factory.CreateClient("InternalApi");

}

}

Typed Client Pattern

For better organization, use the typed client pattern:

builder.Services.AddHttpClient<MyService>(client =>

{

client.BaseAddress = new Uri("https://internal-api.local:5001/");

})

.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler

{

ServerCertificateCustomValidationCallback = (msg, cert, chain, errors) => true

});

With this pattern, MyService gets an HttpClient injected that is pre-configured with the validation callback. Other services in the app get standard validation. This is the most production-friendly way to handle internal APIs with private certificates.

Why HttpClientFactory Matters

Beyond SSL configuration, HttpClientFactory manages the handler lifecycle, prevents socket exhaustion, and centralizes configuration. If you are building an ASP.NET Core application and still creating new HttpClient() directly, switch to HttpClientFactory for both SSL handling and general HTTP best practices.

Solution 4: Adding Certificates to the Trust Store (Proper Fix)

Instead of bypassing validation, you can make the certificate actually trusted by adding it to the system or application trust store. This is the correct fix for development environments and for production apps using private CAs.

Windows Trust Store

On Windows, you can add a certificate to the Trusted Root Certification Authorities store using PowerShell:

Import-Certificate -FilePath "C:\certs\myroot.cer" -CertStoreLocation Cert:\LocalMachine\Root

You need administrator privileges for LocalMachine scope. For per-user scope, use Cert:\CurrentUser\Root.

Adding a Certificate Programmatically in C#

You can also install a certificate from within your .NET application:

var store = new X509Store(StoreName.Root, StoreLocation.LocalMachine);

store.Open(OpenFlags.ReadWrite);

var cert = new X509Certificate2("C:\\certs\\myroot.cer");

store.Add(cert);

store.Close();

This requires the application to run with administrator privileges. It is useful for setup scripts or installation routines but should not be part of normal application startup in production.

Linux Trust Store (Ubuntu/Debian)

On Linux, certificates are managed through the system CA bundle. Copy the certificate to the CA directory and update the bundle:

sudo cp myroot.crt /usr/local/share/ca-certificates/myroot.crt

sudo update-ca-certificates

.NET on Linux uses the OpenSSL trust store, which reads from this bundle. After running update-ca-certificates, .NET HttpClient will trust the added certificate without any code changes.

macOS Trust Store

On macOS, add the certificate to the System keychain:

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain myroot.crt

Why This Is the Recommended Approach

Adding certificates to the trust store is the only solution that fixes the root cause rather than masking the symptom. Once the certificate is trusted, .NET’s built-in validation passes without any custom callbacks or bypass logic. Your code stays clean, and you do not carry validation bypass code into production.

For local development, I recommend using mkcert to generate a locally-trusted development certificate. mkcert automatically installs its root CA in the system trust store, so all certificates it generates are trusted by .NET without any configuration.

Secure Thumbprint-Based Validation Pattern

If you cannot modify the trust store (for example, in a restricted CI/CD environment or a shared hosting scenario), the next best approach is thumbprint-based validation. Instead of blindly returning true, you check that the certificate matches a known, pre-verified thumbprint.

A certificate thumbprint is the SHA-1 hash of the certificate. It uniquely identifies a specific certificate. By checking the thumbprint, you accept only that exact certificate, not any certificate an attacker might present.

The Secure Validation Callback

Here is the production-safe pattern:

private const string ExpectedThumbprint = "A1B2C3D4E5F6...";

var handler = new HttpClientHandler();

handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) =>

{

if (errors == SslPolicyErrors.None) return true;

var thumbprint = cert.GetCertHashString().Replace(":", "").ToUpperInvariant();

return thumbprint == ExpectedThumbprint;

};

var client = new HttpClient(handler);

This callback first checks if the certificate passed all standard validation. If it did, it returns true. If validation failed (for example, due to an untrusted root), it compares the certificate’s thumbprint against the expected value. Only if the thumbprints match does it accept the certificate.

Getting the Thumbprint

You can find a certificate’s thumbprint using PowerShell:

Get-PfxCertificate -FilePath "mycert.cer" | Select-Object Thumbprint

Or by examining it in the Windows Certificate Manager (certmgr.msc). The thumbprint is listed on the Details tab.

Why This Beats “Return True”

The return true pattern shown in most StackOverflow answers accepts any certificate presented by any server. An attacker performing a man-in-the-middle attack would have their certificate accepted without question.

Thumbprint validation prevents this. Even if an attacker intercepts the connection, their certificate will have a different thumbprint and will be rejected. The only risk is certificate rotation: when the server certificate is renewed, the thumbprint changes, and you need to update the expected value.

Store the expected thumbprint in configuration (environment variables, appsettings.json, Azure Key Vault) rather than hardcoding it, so you can update it without recompiling.

Docker and Container Certificate Configuration

Docker containers are a common source of SSL certificate errors in .NET. The base images used for .NET apps (like mcr.microsoft.com/dotnet/aspnet:8.0) come with a minimal set of trusted root certificates. If your containerized app needs to connect to an internal service with a private CA certificate, it will fail validation.

Adding Certificates to a Docker Image

For Debian/Ubuntu-based .NET images, add your CA certificate to the trust store in your Dockerfile:

FROM mcr.microsoft.com/dotnet/aspnet:8.0

COPY myroot.crt /usr/local/share/ca-certificates/myroot.crt

RUN apt-get update && apt-get install -y ca-certificates

RUN update-ca-certificates

The update-ca-certificates command rebuilds the CA bundle, and .NET will pick up the added certificate on the next request.

Alpine-Based Images

For Alpine-based .NET images, the command differs slightly:

FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine

COPY myroot.crt /etc/ssl/certs/myroot.crt

RUN apk add --no-cache ca-certificates && update-ca-certificates

Docker Compose and Volume Mounting

If you do not want to bake the certificate into the image, you can mount it at runtime using Docker Compose:

services:

api:

image: myapp:latest

volumes:

- ./certs/myroot.crt:/usr/local/share/ca-certificates/myroot.crt:ro

command: sh -c "update-ca-certificates && dotnet MyApp.dll"

This keeps the certificate out of the image and makes it easy to update without rebuilding. The command override runs update-ca-certificates before the application starts.

Why Docker SSL Issues Are Common

The core issue is isolation. A Docker container does not share the host’s trust store. Even if you installed the private CA certificate on the host machine, the containerized .NET app cannot see it. Each container manages its own trust store independently.

This is why many teams first encounter SSL certificate errors when containerizing an app that previously ran fine on the host. The certificate that was trusted on the host machine does not exist inside the container.

Troubleshooting Checklist: Diagnosing Your SSL Error

When you hit an SSL certificate error, the generic message tells you almost nothing. Use this checklist to identify the exact cause before applying a fix.

Step 1: Check the Certificate in a Browser

Open the target URL in Chrome or Firefox and click the padlock icon to view certificate details. Check the validity dates, the hostname entries in the SAN field, and whether the browser shows any warnings. This tells you if the certificate itself is valid or if there is a server-side problem.

Step 2: Inspect the Certificate Chain

Use OpenSSL to see the full chain the server sends:

openssl s_client -connect example.com:443 -showcerts

Look for the number of certificates in the chain. If you only see one certificate (the leaf), the server is not sending intermediates. This will cause PartialChain errors in .NET.

Step 3: Add a Diagnostic Validation Callback

Temporarily add a callback that logs the actual error details:

handler.ServerCertificateCustomValidationCallback = (msg, cert, chain, errors) =>

{

Console.WriteLine($"SSL Errors: {errors}");

foreach (var status in chain.ChainStatus)

Console.WriteLine($"Chain Status: {status.Status} - {status.StatusInformation}");

return false;

};

Run your app and check the console output. The errors variable shows the SslPolicyErrors flags, and chain.ChainStatus shows the specific X509ChainStatus entries. This immediately tells you whether you have an untrusted root, a partial chain, a hostname mismatch, or an expired certificate.

Step 4: Test with PowerShell

PowerShell can help you test SSL connections independently of your .NET application:

[Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

Invoke-WebRequest -Uri "https://internal-api.local:5001/" -UseBasicParsing

If this fails, the issue is network-level (firewall, DNS, proxy). If it succeeds, the issue is specifically with .NET’s certificate validation.

Step 5: Check the Certificate Thumbprint

If you plan to use thumbprint-based validation, verify the thumbprint matches what you expect:

Get-PfxCertificate -FilePath "mycert.cer" | Format-List Thumbprint, Subject, NotBefore, NotAfter

Step 6: Check TLS Version Support

Verify which TLS versions the server supports:

openssl s_client -connect example.com:443 -tls1_2

If this fails, the server may not support TLS 1.2, which is the minimum .NET Core accepts by default. You can configure the supported TLS versions on SocketsHttpHandler:

handler.SslOptions.EnabledSslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13;

Step 7: Compare Browser vs .NET Behavior

If the site works in a browser but fails in .NET, the most likely causes are: (1) the browser cached an intermediate certificate that the server is not sending, (2) the browser uses its own trust store that includes the private CA, or (3) the browser ignores certain minor errors that .NET enforces.

Test with curl to get a third opinion: curl -v https://internal-api.local:5001/. Curl uses the OS trust store similar to .NET, so if curl fails but the browser succeeds, you have confirmation that the issue is trust store related.

Security Warnings: Why Blindly Returning True Is Dangerous

Nearly every StackOverflow answer for this error includes the pattern (sender, cert, chain, errors) => true. It works, it is simple, and it is dangerous. The .NET team named the shorthand DangerousAcceptAnyServerCertificateValidator for a reason.

When you return true unconditionally, you are telling .NET to accept any certificate from any server. This means a man-in-the-middle attacker can intercept your HTTPS connection and present their own certificate, and your application will accept it without question.

Man-in-the-Middle Attack Scenario

Consider a microservices architecture where Service A calls Service B over HTTPS. If Service A has SSL validation disabled, an attacker on the network can intercept the connection, present a forged certificate, and read or modify all traffic between the services. The attacker sees API keys, tokens, user data, and any other sensitive information being transmitted.

This is not a theoretical risk. MITM attacks are straightforward on shared networks, compromised Wi-Fi, or any network where an attacker can ARP-spoof or DNS-poison.

Production vs Development

Disabling SSL validation in a local development environment is a pragmatic tradeoff. You are connecting to localhost or a private network with no realistic MITM risk. But that same code, deployed to production, becomes a serious vulnerability.

The problem is that development bypass code often makes it to production. Developers copy the bypass callback from a StackOverflow answer, get it working locally, and commit it without adding guards. Then it ships.

Preventing Accidental Production Exposure

Always guard SSL bypass code with environment checks:

if (builder.Environment.IsDevelopment())

{

handler.ServerCertificateCustomValidationCallback = (msg, cert, chain, errors) => true;

}

Better yet, use thumbprint validation in all environments. It is secure everywhere and does not need environment-specific logic.

Review your codebase for any ServerCertificateCustomValidationCallback or ServerCertificateValidationCallback implementations that return true unconditionally. If they exist outside of development guards, they are security risks that need immediate attention.

FAQs

Conclusion

An SSL certificate shows as untrusted in .NET because the runtime’s certificate validation process cannot verify the server certificate against the system trust store. The fix depends on the root cause, and now you have the tools to identify it and address it correctly.

The seven root causes I covered span self-signed certificates, missing intermediates, expired certificates, hostname mismatches, private CAs, revoked certificates, and TLS version mismatches. Each has a distinct signature in the SslPolicyErrors flags and X509Chain status, which you can surface using a diagnostic validation callback.

When choosing a solution, rank by security. Adding the certificate to the trust store is the best fix because it resolves the root cause without code changes. Thumbprint-based validation is the best code-level approach because it is secure in all environments. Per-handler callbacks with ServerCertificateCustomValidationCallback are fine for development. The DangerousAcceptAnyServerCertificateValidator shorthand and unconditional return true patterns should be confined to local development with environment guards.

If you are migrating from .NET Framework to .NET Core or later and your ServicePointManager callback stopped working, that is expected. Switch to HttpClientHandler.ServerCertificateCustomValidationCallback or use HttpClientFactory with ConfigurePrimaryHttpMessageHandler for the cleanest integration.

For containerized applications, remember that Docker containers do not share the host trust store. Add your CA certificates to the Docker image or mount them at runtime using the approach I showed in the Docker section.

Start with the troubleshooting checklist to diagnose your specific error. Then pick the solution that matches your environment and security requirements. The right answer is almost never return true.