An SSL certificate name mismatch can block secure access, trigger browser warnings, and damage user trust.
This guide explains how to fix SSL certificate name mismatch issues by tracing the exact hostname problem, checking certificate details, and correcting server-side configuration.
What an SSL certificate name mismatch means
An SSL certificate name mismatch occurs when the domain name in the browser address bar does not match the names listed in the certificate.
Browsers verify the requested hostname against the certificate’s Subject Alternative Name, or SAN, and sometimes the Common Name on older certificates.
If the names do not align, the browser cannot confirm that the certificate belongs to the site being visited.
That is why the warning appears even if the certificate is valid, signed by a trusted certificate authority, and not expired.
Common causes of name mismatch errors
Fixing the issue starts with identifying why the hostname is different from what the certificate expects.
In most environments, the root cause is one of these configuration problems.
- The certificate was issued for www.example.com, but visitors are reaching example.com.
- The site uses a subdomain such as app.example.com, but the certificate only covers the root domain.
- The server is presenting the wrong certificate because multiple virtual hosts share the same IP address.
- A load balancer or reverse proxy is serving a default certificate instead of the intended one.
- DNS points users to a different server than the one you updated.
- The certificate includes a typo, an outdated domain, or an incomplete SAN list.
- The site moved to a new hostname, but redirects or application settings were not updated.
How to identify the exact hostname mismatch
Before changing anything, confirm the domain the browser is requesting and the names embedded in the certificate.
This avoids unnecessary changes and helps you fix the actual mismatch rather than masking it.
Check the browser warning details
Modern browsers usually show the domain they expected and the certificate subject information.
Look for the hostname in the address bar, the certificate issuer, and the SAN list.
The mismatch often becomes obvious at this stage.
Inspect the certificate in the browser
Open the certificate details and compare the SAN entries with the domain you are using.
A valid certificate should include every hostname that users may type or that your applications may reference, such as the apex domain, www version, and subdomains.
Use command-line tools for verification
Server-side verification is useful when the browser does not reveal enough detail.
Tools such as OpenSSL can show the certificate being served and the names it contains.
- OpenSSL: run a TLS connection test to inspect the certificate chain and SANs.
- cURL: test whether the hostname resolves and whether the presented certificate matches it.
- DNS lookup tools: confirm that the domain points to the intended server or load balancer.
How to fix SSL certificate name mismatch on the server
Once you know which hostname is failing, the fix usually involves correcting the certificate, the virtual host configuration, or the routing layer.
The most effective solution depends on how your web stack is built.
Reissue the certificate with the correct SANs
If the certificate does not include all required names, reissue it with the full SAN list.
For example, if users access both the root domain and the www version, include both names in the certificate request.
This is the most reliable solution when the certificate was simply generated for the wrong domain.
It is also the right fix when you add a new subdomain and want it protected under the same certificate.
Install the correct certificate on the correct host
In shared hosting, containerized deployments, and multi-site web servers, the server may present the wrong certificate because the wrong file is attached to the wrong site configuration.
Update the certificate paths in your web server configuration and reload the service.
On Apache, nginx, Microsoft IIS, and managed platforms, verify that the hostname-specific binding points to the intended certificate.
A mismatch often persists because the server is still using an older default certificate.
Update virtual host or server name settings
For name-based virtual hosting, the server must recognize the exact hostname requested by the browser.
Check the ServerName, ServerAlias, or equivalent configuration entries and make sure they match the public domain.
If the application listens on multiple hostnames, each hostname should resolve to a certificate that covers it.
Otherwise, the browser may connect successfully but still show a name mismatch warning.
Fix load balancer and reverse proxy certificates
When TLS terminates at a load balancer, CDN, or reverse proxy, the certificate must be installed on that edge layer rather than only on the origin server.
This is a common cause of confusion in AWS, Cloudflare, Nginx Proxy Manager, and Kubernetes ingress setups.
Review the certificate attached to the public-facing endpoint.
If the proxy is serving the wrong certificate, update the listener, edge certificate, or ingress secret so it matches the requested hostnames.
How to fix SSL certificate name mismatch in DNS and redirects
Sometimes the certificate itself is correct, but users are landing on the wrong hostname because of DNS or redirect behavior.
That means the infrastructure must be aligned so the domain a user sees in the browser is actually covered by the certificate.
Align DNS records with the intended hostname
Ensure the domain resolves to the server where the correct certificate is installed.
If the apex domain and subdomain point to different targets, verify that each destination has its own valid certificate or shared certificate coverage.
Review redirect chains
A redirect from HTTP to HTTPS is normal, but redirects between hostnames can create problems if the destination domain is not included in the certificate.
For example, redirecting from an old domain to a new one requires a certificate on the destination domain too.
Check for unnecessary redirect hops, especially if a site moves through several aliases before landing on the final URL.
Make sure canonical URLs match the certificate
Applications, CMS platforms, and reverse proxies often define canonical URLs or base URLs.
If these values point to a hostname not covered by the certificate, users and crawlers may encounter warnings or failed secure requests.
Update the canonical domain in the application settings, environment variables, and SEO metadata if needed.
Special cases that often cause confusion
Some SSL certificate name mismatch problems appear only in specific environments or after infrastructure changes.
These situations are easy to miss during routine checks.
Wildcard certificates
A wildcard certificate for *.example.com covers first-level subdomains such as shop.example.com, but it does not cover the root domain example.com or deeper names like api.dev.example.com.
If users visit those hostnames, a mismatch will still occur.
CDNs and SSL offloading
When using a content delivery network, the edge certificate must match the public hostname.
The origin certificate may also need to match if the CDN verifies origin TLS.
Check both sides of the connection.
Internal hostnames and IP addresses
Certificates are usually issued for domain names, not private IP addresses.
If users access the site by IP or an internal hostname not listed in the SAN, the browser will flag a mismatch.
Use the public hostname or issue a certificate that includes the internal name if your environment requires it.
Best practices to prevent future mismatches
Preventing this error is easier than troubleshooting it after deployment.
A few certificate and hosting practices reduce the chance of a name mismatch returning later.
- Inventory all public hostnames before requesting a certificate.
- Include both apex and www versions when both are used.
- Add new subdomains to certificate planning before launching them.
- Store certificate deployment steps with the server configuration.
- Test the certificate after renewals, migrations, and DNS changes.
- Monitor expiry, SAN coverage, and TLS endpoint behavior regularly.
For larger environments, automate certificate validation during deployment.
That helps catch hostname mismatches before users encounter browser warnings or broken application traffic.
When to renew, reissue, or replace the certificate
If the certificate is expired, renewal alone may not solve the problem unless the SAN entries are still correct.
Reissue the certificate when the hostnames have changed, new subdomains are added, or the old certificate was requested with incomplete naming data.
Replace the certificate entirely if the private key is compromised, the certificate is installed in the wrong environment, or the issuing authority no longer supports the required configuration.
Quick checklist for resolving SSL certificate name mismatch
- Confirm the exact hostname shown in the browser.
- Inspect the certificate SAN list and compare it to the hostname.
- Verify the correct certificate is installed on the public endpoint.
- Check virtual host, proxy, and load balancer settings.
- Review DNS records and redirect targets.
- Reissue the certificate if the hostname is missing.
- Test again after reloading services and clearing cached DNS or browser state.