SSL HOSTNAME TROUBLESHOOTING
How to Fix SSL Certificate Name Mismatch Errors
An SSL certificate name mismatch occurs when the hostname a visitor requests is not covered by the certificate the server presents. A certificate for example.com may omit www.example.com, or the reverse. A subdomain may be missing, the server may present another website’s certificate, or a hosting migration may change how certificates are installed and selected.
Browsers and operating systems describe this problem differently. The familiar term “SSL” refers here to certificates used with modern TLS. Start with the exact failing hostname and the served certificate, rather than assuming that renewal alone will solve the error.
Start with hostname, certificate, and destination
Record the affected hostname, inspect its certificate SANs, confirm where DNS sends traffic, and identify the server or proxy terminating TLS. Correct certificate coverage or selection, then retest each affected hostname. Keep verification enabled and do not bypass browser warnings.
What Is an SSL Certificate Name Mismatch?
When a client connects to HTTPS, it checks the certificate against the hostname it intended to visit. Modern browser hostname validation relies on the appropriate Subject Alternative Name (SAN) entries. The older Common Name (CN) field is not a substitute for missing SAN coverage in modern browsers, even though some historical error names still mention it.
Requested hostname: shop.example.comCertificate SANs: example.com, www.example.com
Result: shop.example.com is not covered
A certificate may be unexpired and issued by a trusted certificate authority, with a chain that verifies correctly, yet fail hostname verification. Date, chain, and hostname checks answer different questions; complete validation requires the applicable checks to pass.
A DNS CNAME does not change the hostname the browser must verify. If shop.example.com points to a hosting provider’s hostname, the endpoint still needs a certificate accepted for shop.example.com. Similarly, visiting an IP address directly requires appropriate IP-address SAN coverage; a DNS-name SAN is not enough.
Common Browser Error Messages
Chrome and Microsoft Edge
NET::ERR_CERT_COMMON_NAME_INVALIDThis representative Chromium error indicates that the certificate does not match the requested identity. Despite the historical Common Name wording, inspect SAN entries and the certificate actually served. Record the address shown when the failure occurs.
Firefox
SSL_ERROR_BAD_CERT_DOMAINFirefox uses this error for a certificate that is not valid for the requested domain. Details may identify the names covered by the certificate. Use those details to distinguish missing coverage from an unexpected server certificate.
Safari
Safari may display a certificate name mismatch or an identity warning. Wording and certificate-viewer controls vary by version and operating system; inspect the warning details rather than treating every identity warning as a hostname problem.
An expired certificate or an unknown certificate authority is a different failure. NET::ERR_CERT_DATE_INVALID and NET::ERR_CERT_AUTHORITY_INVALID should not be relabelled as hostname mismatches. A connection can have several problems, and a client may initially report only one.
Review browser-specific “Your Connection Is Not Private” troubleshooting
How to Check Certificate Hostname Coverage
Use Hostingcone’s published SSL Checker to examine the certificate publicly presented for the exact affected hostname. Checking example.com is not equivalent to checking www.example.com or shop.example.com.
1. Enter the affected hostname.
2. Run the certificate check.
3. Review the certificate Subject Alternative Names.
4. Compare those names with the requested hostname.
5. Examine issuer, validity dates, and reported verification results.
6. Compare the served certificate with the installation you expected.
The checker samples one public address on port 443 using the Hostingcone server’s trust store. Other addresses, regions, and clients can differ. For a proxied domain it normally sees the CDN’s edge certificate, not the origin certificate. A network failure alone does not establish a hostname mismatch.
After a validation failure, any available certificate metadata is labelled as untrusted. It can help identify what was presented, but it is not a successful verification result. If the server returns another site’s names, investigate destination and certificate selection before ordering a replacement.
www vs Non-www Certificate Mismatch
example.com and www.example.com are distinct hostnames. If visitors use both over HTTPS, each initial connection needs an acceptable certificate for the requested name, even when one URL redirects to the other.
An HTTP redirect delivered over HTTPS comes after the TLS connection is validated. Redirecting https://www.example.com to https://example.com therefore cannot repair an invalid certificate on www.example.com. A plain HTTP redirect also does not protect users who start with HTTPS, including browsers with HTTPS-first behavior or HSTS.
If SAN coverage is missing, reissue or replace the certificate to include both names, or use an appropriate SAN/multi-domain certificate. Configure your hosting platform or certificate automation to request and renew both hostnames. If coverage already exists, confirm that the server selects that certificate for both names.
Check the DNS destinations of both hostnames as well. Adding names to a certificate installed on one server will not help if www still routes visitors to a different server presenting its own certificate.
Subdomain Certificate Mismatch
app.example.com, shop.example.com, and mail.example.com each need appropriate hostname coverage. For a mail service, also check the actual client protocol and TLS listener; an HTTPS check on port 443 does not verify SMTP or IMAP certificates.
What *.example.com covers
Wildcard SAN: *.example.comCovered: app.example.com, shop.example.com, mail.example.com
Not covered by this SAN: example.com, a.shop.example.com
A wildcard normally matches one subdomain label. It does not automatically include the bare domain or deeper nested names. A certificate can separately list example.com alongside *.example.com; verify its actual SAN entries rather than inferring coverage from a product name.
Use explicit SAN entries or a suitable wildcard at the required level when the provider supports it. Every requested name remains subject to the issuer’s validation requirements. Do not buy a wildcard before confirming which hostname is failing and whether the correct certificate is being served.
Wrong Certificate Installed on the Server
A TLS listener can present the wrong certificate because it is assigned to the wrong virtual host, a shared-hosting domain mapping is incorrect, SNI selection is misconfigured, or the certificate was installed on a server visitors do not reach. Incomplete deployment across load-balanced servers can make failures intermittent.
Server Name Indication (SNI) lets a client send the intended server name during the TLS handshake so a shared endpoint can select the right certificate. SNI selection and certificate hostname verification are separate: selecting a certificate does not prove that its SANs match.
Inspect the certificate externally using the exact hostname and SNI. Compare its SANs, issuer, serial number or fingerprint, and dates with the intended certificate. Check affected IPv4 and IPv6 destinations and each relevant TLS termination point; a control-panel installation status is not proof of what every visitor receives.
When a reverse proxy, CDN, or load balancer terminates TLS, its certificate can be different from the backend certificate. Identify the failing connection before changing files on the web server. Use your platform’s supported mapping and deployment process, protect private keys, and retest after activation.
SSL Name Mismatch After Website Migration
After a hosting move, DNS may still point to the old server, or the new host may not yet have the right certificate installed. www, the bare domain, and subdomains can follow different destinations. Old AAAA records can send IPv6 visitors elsewhere even when the A record is correct.
Review virtual hosts, CDN origins, and load-balancer nodes. Newly added hostnames may have been omitted from certificate requests or renewal configuration. Where older endpoints remain reachable during the transition, maintain valid certificates there as well.
Separate routing from coverage: DNS determines which destination is reached; the certificate must cover the original requested hostname at the TLS endpoint. If DNS sends traffic to an unintended host, correct that routing. If the intended host is reached but serves an unsuitable certificate, correct coverage or certificate selection there.
Resolvers may retain old answers according to existing TTLs. Lowering a TTL now does not remove answers already cached under its old value. Compare authoritative and recursive answers; do not promise a fixed propagation deadline or assume waiting will repair a wrong certificate.
Understand DNS propagation and cached destinations after a migration
Cloudflare SSL Certificate Name Mismatch
A proxied website has two TLS connections: visitor-to-Cloudflare and Cloudflare-to-origin. Browsers normally evaluate the edge certificate. The origin certificate is evaluated separately under the configured origin connection policy; an edge check cannot prove origin validity.
Confirm that the requested hostname is covered by an active Cloudflare edge certificate. Coverage depends on the zone setup and certificate product; deeper subdomains may need additional coverage. Do not assume a universal wildcard includes every nested hostname.
Under Full (strict), the origin certificate must meet the applicable trust, validity, and hostname requirements. Review the name Cloudflare uses for origin verification, including deliberate origin/SNI overrides, and the certificate served by that listener. Origin misconfiguration can produce a Cloudflare error rather than a browser warning about the edge certificate.
Cloudflare Origin CA certificates are intended for Cloudflare-to-origin connections and are not generally trusted by ordinary browsers connecting directly to the origin. Direct-access trust failures and hostname mismatches are separate checks. A certificate suitable for that private origin connection still needs the correct names.
Correct the failing connection’s certificate coverage, activation, or selection. Do not switch to Flexible SSL or disable verification to hide the problem. The hosting provider and Cloudflare administrator may need to coordinate; keep the security requirements of both layers intact.
How to Diagnose With OpenSSL
With a supported OpenSSL installation, replace all three occurrences of example.com with the exact affected hostname:
openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error-connect chooses the destination and port. -servername sends SNI for certificate selection. -verify_hostname checks whether the presented certificate covers the intended hostname, while -verify_return_error makes verification errors fail the connection rather than just logging them and continuing.
Read the verification result and any error text. A hostname mismatch can cause verification failure even when the issuer chain is trusted. Verification also depends on the local CA store; an unknown issuer is not a hostname mismatch. A successful handshake without appropriate identity checks does not prove hostname validity.
OpenSSL options and behavior vary by version; consult openssl s_client -help if a flag is unavailable. This example may stay open interactively after connection; use Ctrl+C after collecting the result. It does not reproduce every browser policy or automatically perform every revocation check.
Inspect the presented leaf certificate
In a POSIX-compatible shell on macOS or Linux, this separate metadata command displays the first served certificate’s subject, issuer, dates, SANs, and SHA-256 fingerprint:
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256This pipeline is for inspecting certificate metadata, not proving successful validation: it suppresses connection diagnostics and its final exit status can reflect only the x509 parser. Use the verification command separately. /dev/null redirection is POSIX shell syntax and should not be pasted unchanged into Windows PowerShell or Command Prompt.
To test a specific known endpoint, replace only the -connect destination with its IP address and port, keeping -servername and -verify_hostname set to the original website hostname. Use brackets for an IPv6 address with a port. This isolates certificate selection at that destination without changing public DNS.
How to Fix SSL Certificate Name Mismatch
1. Identify the exact failing hostname, URL, and browser error.
2. Inspect the served certificate’s SAN entries.
3. Confirm the hostname’s current DNS destination, including A and AAAA paths.
4. Determine which server, CDN, or proxy presents the certificate.
5. Confirm the intended certificate and matching key are installed there.
6. Reissue or replace the certificate if required hostname coverage is missing.
7. Check virtual-host mapping, SNI selection, and deployment across relevant endpoints.
8. Retest every affected hostname externally and review any remaining date or chain failures.
Contact the hosting or DNS provider if you cannot inspect the intended listener, shared-host mapping, certificate automation, or destination. Ask the CDN administrator about edge coverage and origin verification when a proxy is involved. The website owner must correct a server-side mismatch; a visitor should not bypass it.
Provide the hostname, error code, time of failure, public certificate details, recent DNS or migration changes, and whether other networks show the same result. Do not send private keys, passwords, API tokens, or sensitive customer information in an ordinary support message.
Check certificate expiration and renewal deployment separately
SSL Certificates and Professional Assistance
Hostingcone’s published SSL Certificates page explains its HTTPS certificate offerings and links to current store options. Choose coverage and management arrangements that suit the hostnames you actually use; a paid certificate is not automatically a stronger encryption solution.
Compare free and paid SSL certificate options
Website Care is the ongoing maintenance and support route, with work depending on the plan purchased. Website Repair addresses website errors, configuration problems, and functionality issues through its existing service-request workflow. Use the relevant published page to review current scope and pricing; no additional certificate work is assumed to be included.
Explore Website Care for ongoing maintenance and support
Review Website Repair scope and request assistance
Investigation can depend on access, third-party platforms, DNS providers, proxies, and the hosting environment. Agree on scope before work begins. These services do not guarantee that every issue will be resolved or every website security risk eliminated.
Frequently Asked Questions
What causes an SSL certificate name mismatch?
The served certificate does not cover the hostname the client requests. Missing SANs, an incorrect virtual host, stale DNS routing, or inconsistent proxy/server deployment can cause it.
Why does SSL work on example.com but not www.example.com?
They are different hostnames and may have different certificate coverage or DNS destinations. Verify SAN entries and the certificate actually served for each name; a redirect cannot fix an invalid initial HTTPS connection.
Can a wildcard SSL certificate fix hostname mismatch?
It can address missing coverage for a matching single-level subdomain when correctly issued and deployed. It will not fix a wrong server certificate, unrelated hostname, bare-domain omission, or deeper name outside the wildcard’s coverage.
Does a wildcard certificate cover the root domain?
Not by the wildcard SAN alone. *.example.com does not match example.com. A certificate can include example.com as an additional SAN; check the actual names listed.
What is the difference between CN and SAN?
CN is the Common Name in the certificate subject. SAN lists identities such as DNS names and IP addresses. Modern browser hostname verification relies on appropriate SAN entries; CN is not a fallback for missing SAN coverage.
Why does my server show another website's certificate?
The connection may reach the wrong destination or a default/shared-host certificate because domain mapping, SNI, virtual-host selection, or proxy configuration is incorrect. Check the exact hostname and endpoint before replacing certificates.
Can DNS changes cause a certificate name mismatch?
Yes, by routing clients to an endpoint with an unsuitable certificate. DNS does not rewrite the certificate’s SANs or change the requested identity. Check both the route and coverage at the destination.
Can Cloudflare fix SSL hostname mismatches?
Appropriate edge coverage can resolve a mismatch at the visitor-facing layer, but origin verification remains separate. Check the relevant edge and origin configuration; do not weaken validation as a workaround.
How do I check which hostnames my certificate covers?
Inspect Subject Alternative Names using Hostingcone’s SSL Checker, your browser’s certificate viewer, or OpenSSL. Test the exact hostname; results for the bare domain do not prove coverage for www or other subdomains.
Is it safe to ignore a certificate name mismatch warning?
Do not bypass it or submit sensitive information. The client cannot validate the server for the requested identity. Recheck the URL and contact the website owner or responsible provider to resolve the cause.
Fix SSL Certificate Errors Before They Affect Visitors
Check your website’s certificate coverage, expiration, and validation details, or explore Hostingcone’s SSL solutions and website troubleshooting services.
Explore Website Care for ongoing website support
Find more certificate troubleshooting guides in Hostingcone’s SSL Troubleshooting Hub.