CERT_E_CN_NO_MATCH (0X800B010F) Fix: 3 Steps

What's Actually Happening Here

You're seeing CERT_E_CN_NO_MATCH (0X800B010F) because the SSL/TLS certificate on the server has a Common Name (CN) that doesn't match the hostname you typed into your browser, your PowerShell command, or your application connection string. The server says "I'm example.com" but you're hitting api.example.org or an IP address directly. Windows is doing exactly what it should — refusing to trust a certificate that doesn't match the target.

This error is especially common when:

• You're using an IP address instead of a hostname (certificates are issued to names, not IPs)
• The certificate expired and someone renewed it with a different CN
• You have a wildcard certificate like *.example.com but you're hitting subdomain.example.org
• A reverse proxy or load balancer is terminating SSL but passing the request to a backend with a mismatched cert

Let's walk through the fixes from simplest to most invasive. Stop when the error goes away.

1. The 30-Second Fix: Use the Correct Hostname

This sounds obvious, but it's the fix in maybe 60% of cases. Open the certificate and check the CN field. Here's how on Windows:

1. Open the failing URL in a browser
2. Click the padlock icon in the address bar → Certificate
3. Look at the Issued To field — that's the CN
4. Now type exactly that hostname into your browser, not the IP, not a different subdomain

If you're in PowerShell trying to connect to https://192.168.1.50:8443, that IP isn't in the cert. Use the hostname instead:

# Wrong — will trigger CERT_E_CN_NO_MATCH
Invoke-WebRequest -Uri 'https://192.168.1.50:8443'

# Right — uses the cert's CN
Invoke-WebRequest -Uri 'https://server01.internal.company.com:8443'

If your DNS doesn't resolve that hostname, add it to your hosts file (C:\Windows\System32\drivers\etc\hosts) or update DNS. Don't try to bypass the check — that teaches bad habits and breaks other security tools.

2. The 5-Minute Fix: Update or Replace the Certificate

If the hostname is correct but the CN is still wrong, you need to fix the certificate itself. This happens when:

• The certificate is expired or about to expire
• Someone generated a self-signed cert for testing with the wrong CN
• You're using a wildcard cert but the subdomain doesn't match the wildcard pattern

Check the certificate details first. Open the certificate from the error dialog or use certlm.msc (Local Machine store) or certmgr.msc (Current User store). Look at the Details tab → Subject field. You want something like CN=api.example.com. If it says CN=localhost or CN=*.example.com and you're hitting api.example.com — that wildcard works. But if it says CN=*.example.com and you're hitting api.other.com — mismatch.

To replace the certificate in IIS:

1. Open IIS Manager
2. Select your site → Bindings
3. Edit the HTTPS binding → change the SSL certificate dropdown to the correct one
4. Apply and restart the site

To generate a new self-signed cert with the correct CN (PowerShell):

New-SelfSignedCertificate -DnsName "api.example.com" -CertStoreLocation "Cert:\LocalMachine\My"

The -DnsName parameter sets both the CN and the Subject Alternative Name (SAN), which is the modern way to do it. SANs are more flexible than CN alone — you can list multiple hostnames.

For a real CA-issued certificate, you need a new CSR with the correct CN. Contact your CA or use your internal PKI. Most modern CAs will also require SANs. If you're using Let's Encrypt, you can request a certificate with multiple domains via certbot or similar tools.

3. The 15+ Minute Fix: Check Certificate Chains and Revocation

If the CN is correct and the certificate is valid, but the error persists, you're dealing with a deeper issue. The error code 0X800B010F can also fire when Windows can't build the certificate chain or revocation check fails and the system falls back to CN validation as a misdiagnosis. I've seen this on systems where:

• The intermediate CA certificate is missing from the Intermediate Certification Authorities store
• Certificate revocation lists (CRLs) are unreachable (common on air-gapped networks)
• The system clock is wrong by more than a few minutes

Step 1: Verify the certificate chain

Open the certificate → Certification Path tab. Every certificate in the chain should show a green checkmark. If any shows a red X or yellow warning, you're missing a CA cert.

• Missing intermediate CA? Download it from your CA's website or the issuing CA, then import it into Local Machine → Intermediate Certification Authorities using certlm.msc.
• Root CA not trusted? Import the root CA into Trusted Root Certification Authorities.

Step 2: Check revocation behavior

If you're on a domain-joined machine or behind a strict firewall, CRL checking might hang or fail. Windows then may fail the connection with a generic error that looks like CN mismatch. To test:

1. Open Internet Options → Advanced tab
2. Scroll to Security section
3. Uncheck Check for publisher's certificate revocation
4. Uncheck Check for server certificate revocation
5. Try the connection again

If the error disappears after disabling revocation checks, the fix is to allow CRL access in your firewall or configure a local CRL distribution point. Don't leave revocation checking disabled — that's a security downgrade.

Step 3: Use a tool to diagnose the exact issue

Run certutil to verify the certificate chain:

certutil -urlfetch -verify server_cert.cer

Replace server_cert.cer with the actual certificate file. The output will show you exactly which step fails — missing intermediate, bad AIA extension, CRL timeout. Pay attention to lines that say FAILED or Expired.

Step 4: For developers — bypass in code (only for debugging)

If you're writing code and hit this error in development, you can bypass validation temporarily. Never do this in production.

In .NET with HttpClient:

var handler = new HttpClientHandler {
    ServerCertificateCustomValidationCallback = (sender, cert, chain, sslPolicyErrors) => true
};
var client = new HttpClient(handler);

In Python with requests:

import requests
response = requests.get('https://192.168.1.50:8443', verify=False)

This is a debug-only escape hatch. The real fix is to get a proper certificate or configure the correct hostname.

How to Avoid This Error Going Forward

• Always use hostnames, not IPs, in URLs and connection strings. Certificates are tied to DNS names.
• Use Subject Alternative Names (SANs). Modern browsers and Windows ignore the CN if SANs are present. A cert can have CN=whatever but if the SAN contains the hostname you're using, it works.
• Set up proper DNS. If you can't resolve the cert's CN to an IP, you'll always fight this error.
• Keep your root and intermediate CA certs updated. Group Policy can push them to domain machines automatically.

The 0X800B010F error is Windows telling you, plainly, that the server's identity doesn't match what you asked for. Listen to it, fix the mismatch, and your connection will be secure and silent.