SSL & HTTPS Guides

Fixing Domain Mismatch Errors in SSL Certificates

Learn why SSL certificate domain mismatch errors happen, how to check covered hostnames, and how to fix certificates for root, www and subdomains.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 8 min read Beginner

Introduction

A domain mismatch error happens when the SSL/TLS certificate shown by the server does not cover the exact hostname visitors are using. For example, the certificate may cover example.com but not www.example.com, or it may cover one subdomain while visitors open another.

This problem is common after hosting migrations, CDN changes, domain redirects, wildcard certificate mistakes or incorrect virtual host configuration. The fix is to identify the hostname visitors use, check the certificate SAN list, and install a certificate that covers the active domain.

Quick answer

Quick answer

A certificate mismatch means the certificate does not include the hostname being visited. Check the exact URL, review the certificate SAN names, confirm root/www/subdomain coverage, and install or reissue a certificate that covers the active hostname.

SSL domain mismatch

An SSL domain mismatch means the browser connected to one hostname, but the server presented a certificate issued for a different hostname.

Example 
Visitor opens:
https://www.example.com

Certificate only covers:
example.com

Result:
Browser may show a certificate warning.

The certificate must match the exact hostname in the browser address bar, unless the hostname is covered by a valid wildcard or SAN entry.

Hostname matching

SSL certificates are checked against the hostname visitors use.

  • example.com
  • www.example.com
  • app.example.com
  • mail.example.com
  • dev.app.example.com

These are not automatically the same for SSL coverage.

A redirect can help choose one preferred hostname, but the certificate still needs to be valid for the hostname before or during the HTTPS connection.

SAN names

Modern certificates list covered hostnames in the Subject Alternative Name, or SAN, field.

Example SAN list 
example.com
www.example.com
app.example.com

This certificate covers those exact names. It does not cover shop.example.com, api.example.com or dev.app.example.com unless those names are also listed.

When troubleshooting mismatch errors, always check the SAN list.

Root vs www

The root domain and www hostname are different names.

Root

example.com

WWW

www.example.com

A certificate for only example.com may not cover www.example.com. A certificate for only www.example.com may not cover example.com.

  • Include both example.com and www.example.com, or
  • Redirect consistently to the hostname covered by the certificate

For most public websites, include both root and www to avoid avoidable warnings.

Wildcard mismatch

Wildcard certificates cover only one subdomain level.

Example wildcard 
*.example.com

Covers:

  • app.example.com
  • shop.example.com
  • blog.example.com

Usually does not cover:

  • example.com
  • dev.app.example.com
  • example.net

If you need deeper subdomains, add specific SAN names or use another certificate strategy.

Why this matters

Why this matters

Domain mismatch errors matter because browsers treat them as serious security warnings. Visitors may think the site is fake, compromised or unsafe. APIs, webhooks, payment systems and integrations may also reject connections when the certificate does not match the hostname.

Mismatch errors usually mean the wrong certificate is installed, the wrong hostname is being used, or the active server or CDN is not serving the expected certificate.

How to check mismatch

Use SSL Checker to inspect the certificate shown for the exact hostname visitors use.

When checking mismatch errors, review

These six checks help identify hostname coverage gaps.

Exact URL

Check the full hostname in the browser address bar.

Certificate SAN list

Confirm whether the hostname appears in the certificate.

Root and www

Check both example.com and www.example.com.

Subdomains

Check each subdomain that should load over HTTPS.

Active server or CDN

Confirm which endpoint is serving the certificate.

Redirect behavior

Check whether redirects send users to a hostname not covered by the certificate.

Check hostname coverage

Use SSL Checker to verify whether the certificate covers the exact domain or subdomain.

Run SSL Check →

Common problems

Certificate covers root but not www

High

Visitors open www.example.com, but the certificate only includes example.com.

Next step: Reissue the certificate with both example.com and www.example.com, or redirect consistently.

Certificate covers www but not root

High

Visitors open example.com, but the certificate only includes www.example.com.

Next step: Add the root domain to the certificate or redirect root to www with valid coverage.

Wrong certificate installed

High

The server presents a certificate for another domain or old hosting account.

Next step: Install the correct certificate on the active server, CDN or proxy.

Subdomain not included

High

The certificate does not include the requested subdomain.

Next step: Add the subdomain to the SAN list or use a suitable wildcard certificate.

Wildcard does not cover deeper subdomain

Medium

*.example.com does not normally cover dev.app.example.com.

Next step: Issue a certificate that includes the deeper hostname explicitly.

CDN serves different certificate

High

The origin server may be correct, but the CDN edge presents another certificate.

Next step: Update the certificate in the CDN or proxy settings.

Redirect points to uncovered hostname

Medium

The site redirects users to a hostname not included in the certificate.

Next step: Fix redirects or add the redirect target hostname to the certificate.

Old certificate cached or still active

Medium

A new certificate was issued, but the public endpoint still serves the old one.

Next step: Reload the web server, update CDN/proxy SSL and clear relevant caches.

How to fix mismatch

  1. Step 1: Identify the exact failing hostname

    Check the hostname users open, such as example.com, www.example.com or app.example.com.

  2. Step 2: Inspect the certificate SAN list

    Use SSL Checker or browser certificate details to see which hostnames are covered.

  3. Step 3: Decide the intended hostname strategy

    Choose whether the site should use root, www, a subdomain or multiple names.

  4. Step 4: Reissue the certificate

    Include every hostname that should load over HTTPS.

  5. Step 5: Install on the active endpoint

    Update the certificate on hosting, CDN, reverse proxy, load balancer or control panel.

  6. Step 6: Fix redirects

    Make sure redirects send users only to hostnames covered by the certificate.

  7. Step 7: Re-test externally

    Check every public hostname after installation.

CDN and proxy mismatch

If a CDN or reverse proxy is used, visitors may not see the certificate installed on the origin server. They see the certificate served by the CDN or proxy edge.

  • CDN SSL certificate
  • Origin SSL certificate
  • Proxy mode
  • Custom hostname settings
  • Edge certificate coverage
  • Origin hostname coverage
  • Redirect rules at CDN and origin

A mismatch can happen even when the origin server certificate is correct if the CDN edge certificate is wrong.

Migration checklist

After moving hosting or CDN, check

Verify every public hostname after migration.

Root domain

Root domain certificate is valid.

WWW

WWW certificate is valid.

Subdomains

Important subdomains are covered.

Wildcard

Wildcard coverage matches actual hostnames.

CDN edge

CDN edge certificate is correct.

Origin cert

Origin certificate is correct.

Redirect targets

Redirect targets are covered.

Old server

Old server is not still responding.

DNS endpoint

DNS points to the intended endpoint.

External HTTPS

HTTPS works from an external network.

Mismatch examples

Root vs www problem 
Visitor opens:
https://www.example.com

Certificate covers:
example.com

Fix — issue certificate for:
example.com
www.example.com
Deeper subdomain problem 
Visitor opens:
https://dev.app.example.com

Certificate covers:
*.example.com

Fix — add:
dev.app.example.com

or use a separate certificate for that hostname.
Check commands 
openssl s_client -connect www.example.com:443 -servername www.example.com
curl -I https://www.example.com

These examples are illustrative. Replace hostnames with your real domain names.

Frequently asked questions

What causes an SSL domain mismatch?

The certificate does not include the exact hostname visitors are using.

Does example.com certificate cover www.example.com?

Only if www.example.com is included in the certificate SAN list.

Does a wildcard certificate cover the root domain?

Usually no. *.example.com covers first-level subdomains, not example.com.

Does a wildcard certificate cover dev.app.example.com?

Usually no. *.example.com covers app.example.com, but not deeper subdomains like dev.app.example.com.

Why does the mismatch happen only behind a CDN?

The CDN may be serving its own edge certificate, which can differ from the origin server certificate.

Can redirects fix a mismatch?

Only if the browser can establish a valid HTTPS connection first. The certificate still needs to cover the hostname being requested.

How do I confirm the fix worked?

Run SSL Checker and test every hostname externally, including root, www and important subdomains.

Use these free tools to verify your configuration after applying changes.

SSL Checker DNS Lookup CAA Record Checker Website Status Checker Domain Health Checker
How to Check Your SSL Certificate 8 min read Wildcard vs SAN Certificates: Which One Should You Choose 7 min read WWW vs Non-WWW: SSL Certificates and HTTPS Consistency 8 min read SSL Certificate Renewal Failures: Common Causes and Fixes 8 min read Troubleshooting SSL Handshake Failures 9 min read
Browse all SSL & HTTPS guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.