Certificate Name Mismatch Errors

Certificate name mismatch errors occur when the domain in your browser doesn't match any name in the server's certificate. This check exists for a critical reason: without it, an attacker who steals any website's certificate could use it to impersonate any other website.

What Triggers a Name Mismatch?

When you visit https://example.com, your browser checks whether "example.com" appears in the certificate's list of authorized names. If it doesn't, you see errors like "ERR_CERT_COMMON_NAME_INVALID" or "The certificate is valid for X but you requested Y."

The certificate contains this list in its Subject Alternative Names (SAN) extension. Modern browsers check only the SAN field—the older Common Name (CN) field is ignored. Always put your domain names in SAN, even if there's only one.

The www Trap

The most common mismatch catches almost everyone at some point:

A certificate for www.example.com does not cover example.com. They're different hostnames. To TLS, they're as distinct as example.com and otherdomain.org.

The fix is simple—include both:

certbot certonly -d example.com -d www.example.com

This creates one certificate covering both names. Do this for every certificate unless you're absolutely certain your redirects are bulletproof.

Wildcard Certificates: The Asterisk Gotcha

Wildcard certificates cover subdomains, but with a surprising limitation:

*.example.com covers:

• mail.example.com ✓
• api.example.com ✓
• blog.example.com ✓
• anything.example.com ✓

*.example.com does NOT cover:

• example.com ✗ (the base domain)
• api.blog.example.com ✗ (multi-level subdomains)

The asterisk means "something must be here," not "something might be here." If you need both the wildcard and the base domain:

certbot certonly -d example.com -d *.example.com

Note: Let's Encrypt requires DNS validation (not HTTP) for wildcard certificates.

IP Address Access

Visiting https://192.168.1.100 when the certificate is for example.com creates a mismatch. The certificate authorizes a name, not a number.

This happens when users type IPs directly, bookmarks contain IPs, or DNS fails and something falls back to an IP. The solution isn't adding IPs to certificates—IPs change, and certificates become invalid. Instead:

• Redirect IP access to the proper domain
• Use DNS even on local networks
• Train users to use domain names

Multiple Domains on One Server

If example.com, example.org, and example.net all point to the same server, you need all of them in the certificate:

certbot certonly -d example.com -d example.org -d example.net \
  -d www.example.com -d www.example.org -d www.example.net

Let's Encrypt allows up to 100 domains per certificate.

Diagnosing the Mismatch

Read the error message. Browsers tell you exactly what went wrong: "Certificate is valid for www.example.com but you requested example.com."

View the certificate. Click the padlock → View Certificate → look at Subject Alternative Names. That's the complete list of what the certificate covers.

Command line:

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -text | grep DNS:

SSL Labs: Run ssllabs.com/ssltest to see all domains in the certificate and check for mismatches.

Fixing the Mismatch

1. List every domain users actually type. Include www and non-www, alternative TLDs, subdomains, and old domains that should redirect.

2. Get a certificate with all of them:

certbot certonly -d example.com -d www.example.com -d blog.example.com

3. Set up redirects. Pick a canonical URL (www or non-www) and redirect everything else to it. Use 301 (permanent) redirects.

4. Test every variation. Each domain should either work directly or redirect to one that does.

Server Name Indication (SNI)

SNI lets one server present different certificates for different domains. Instead of cramming unrelated sites into one certificate, configure separate certificates and let the server choose based on which hostname the client requests.

Modern web servers handle this automatically when you configure multiple virtual hosts with different certificates.

Adding Domains Later

With Let's Encrypt, request a new certificate listing all domains (existing plus new):

certbot certonly -d example.com -d www.example.com -d new.example.com

Certbot replaces the old certificate. Commercial CAs may charge fees to add domains or require purchasing a new certificate.

Multi-Level Subdomains

*.example.com covers blog.example.com but not api.blog.example.com. For multi-level subdomains:

• List them explicitly: -d api.blog.example.com
• Use nested wildcards: -d *.blog.example.com
• Use separate certificates with SNI

For complex subdomain structures, explicit listing is often clearer than wildcard gymnastics.