CERT_E_INVALID_NAME (0x800B0114) – The Real Fix
That certificate name mismatch error is infuriating. Here's the exact fix and why it happens.
That “Certificate has an invalid name” error is a real head-scratcher, especially when you're sure the cert is valid.
You're hitting 0x800B0114 (CERT_E_INVALID_NAME). What's actually happening is Windows is refusing to trust the server because the name in the certificate doesn't match the name you used to connect. This isn't a trust problem with the CA — it's a name mismatch problem. The cert is valid, but it's valid for a different hostname.
The Fix: Match Your Connection to the Certificate
- Check what name the certificate expects. Open a browser, hit the site, and click the padlock icon. View the certificate. Look at the Subject (CN) or the Subject Alternative Name (SAN) list. The Common Name is the primary hostname. The SANs are a list of alternate names the cert covers. You need to connect using exactly one of those names.
- Adjust your URL. If you typed
https://server.internal.company.combut the cert saysCN=server.company.com— that's the mismatch. Use the name in the cert. No exception. The browser or OS won't bend on this. - If you control the server, regenerate the cert. Include every name you need in the SAN list. Modern browsers barely look at the CN anymore — they rely on SANs. A cert with
CN=example.combut nowww.example.comin the SAN will fail for the latter. AddDNS:www.example.comto the SAN. - For internal or legacy apps, add the name to the hosts file as a temporary test. This isn't a real fix, but it confirms the issue. Edit
C:\Windows\System32\drivers\etc\hostsand map the cert name to the IP. If the error goes away, you've confirmed it's a name mismatch. - Override the check in code (only if you really need to). In .NET apps, you can set
ServicePointManager.ServerCertificateValidationCallbackto ignore name mismatches. This is a bad idea for production, but useful for debugging or internal tools where you control every client. You'll see this pattern in old WinForms apps hitting self-signed certs. Don't ship it to customers.
Why This Fix Works
The error code 0x800B0114 maps to CERT_E_INVALID_NAME in the Windows CryptoAPI. The API does two checks when building a certificate chain: first, it verifies the cert is trusted (issued by a trusted CA, not expired, not revoked). Second, it checks the name. The name verification is strict. It compares the hostname in the URL against the CN and all SANs. If none match, it returns this error. Even if the cert is perfectly valid otherwise. So the fix isn't about fixing the cert's trust — it's about making the name match. The reason step 3 works is you're telling the CA (or yourself) exactly what names you need, so the cert covers them. Without that, you get the mismatch.
Less Common Variations
Wildcard mismatch
A wildcard cert (*.example.com) covers www.example.com and mail.example.com, but not example.com (no subdomain) and not sub.www.example.com (two levels deep). If you're connecting to https://example.com and the cert is *.example.com, you'll get this error. Fix: connect to https://www.example.com or get a cert that explicitly includes the bare domain.
IP address vs hostname
You can't use an IP address with a cert that lists hostnames. Some old internal CAs issue certs with IPs in the SAN. If you try to connect via hostname but the SAN has an IP, it fails. Check the SAN list for IP addresses. If it has IP:10.0.0.5, you must connect to https://10.0.0.5 — not the hostname. This catches people off guard in enterprise environments.
Case sensitivity and trailing dots
Most implementations ignore case, but not all. If the cert says mail.example.com and you connect to Mail.example.com, some older clients (looking at you, Internet Explorer 8) will reject it. Also, a trailing dot in the URL (example.com.) is treated as a different name. Unlikely in modern browsers, but possible in custom scripts or PowerShell commands. Strip trailing dots.
Certificate issued to a different port
A cert doesn't care about ports — it cares about hostnames. But some software incorrectly generates certs with the port number in the CN, like server.example.com:443. That's invalid. The CN should never contain a port. If you see that, regenerate the cert.
Prevention
Plan your names before requesting a cert. List every hostname, subdomain, and IP (if needed) that will ever hit this server. Put them all in the SAN. For internal servers, use a naming convention that matches the cert's CN. Don't use bare IPs unless you absolutely have to. And if you're using Let's Encrypt or a similar automated CA, make sure your DNS records match what you request — a mismatch between the A record and the cert's name is the most common cause of this error in 2024. For self-signed certs, use PowerShell's New-SelfSignedCertificate with the -TextExtension parameter to manually add SANs. The default PowerShell behavior often omits them, which is why people hit this error with local dev certs.
Finally, if you're on Windows Server and using IIS, the Server Name Indication (SNI) feature can also cause this if you bind a cert to a hostname that doesn't match the request. Double-check your site bindings in IIS Manager. A misconfigured SNI binding will throw this exact error, even if the cert itself is correct.
Was this solution helpful?