Skip to content
Rescue 404
Rescue

SSL and HTTPS Problems

SSL certificate name mismatch

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

An SSL certificate name mismatch means the certificate’s DNS names do not include the hostname the browser requested—reissue or replace the certificate so the apex, www, and any live subdomains you use appear in the Subject Alternative Name list, then point HTTPS at that cert.

Browsers refuse to trust a certificate that belongs to a different hostname, even when dates and the issuing CA look fine. WordPress sites hit this after domain changes, partial Let’s Encrypt coverage, wrong vhost certificates, or CDN/host mismatches. This Website Repair guide shows how to read the names on the cert, cover every hostname visitors actually type, and clear the interstitial without weakening TLS checks.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

What the error means

During TLS, the browser checks that the certificate presented for the TCP connection is valid for the host in the URL. Modern checks use Subject Alternative Name (SAN) DNS entries (legacy commonName alone is not enough to rely on). If you open `https://www.example.com` but the certificate only lists `example.com`—or still lists the old staging domain—Chromium reports errors such as NET::ERR_CERT_COMMON_NAME_INVALID and the UI describes a name mismatch. That is not expiry (CERT_DATE_INVALID) and not “missing HTTPS redirects”; the handshake completed with the wrong identity. Shared hosting and reverse proxies sometimes attach the default server certificate when the vhost or Cloudflare origin hostname is wrong, so visitors see a cert for an unrelated domain on the same IP. Fixing it means installing a certificate that explicitly includes every hostname in use, correcting DNS/vhost mapping so the right cert is selected, and updating WordPress siteurl/home so the site does not send people to an uncovered host.

Common symptoms

  • Browser warns that the certificate is not valid for this name / NET::ERR_CERT_COMMON_NAME_INVALID
  • Certificate viewer shows SANs that omit the hostname in the address bar
  • www works with a valid padlock while the apex (or a subdomain) fails—or the reverse
  • After a domain change, HTTPS still presents a certificate for the old domain
  • SSL checkers report “certificate name mismatch” or “does not match hostname”
  • Direct IP access or a wrong vhost shows another customer’s or the server default certificate
  • Cloudflare Full (strict) fails while Flexible/Full appear to “work” with a mismatched origin cert

Most likely causes

  1. 01 Certificate issued only for example.com while traffic uses www.example.com (or the opposite)
  2. 02 New domain or subdomain never added to the SAN list before DNS cutover
  3. 03 Hosting still serving a default or neighbor vhost certificate for the requested Host header
  4. 04 WordPress/site redirects sending users to a hostname the certificate does not cover
  5. 05 Stale Cloudflare custom hostname or origin certificate tied to the previous domain
  6. 06 Wildcard cert expected but not issued (or not installed) for deeper subdomains
  7. 07 Load balancer or reverse proxy presenting its own cert instead of the site’s certificate

What changed before the problem started

  • Primary domain or www preference changed in WordPress, host panel, or DNS
  • Site migrated to a new hostname without reissuing SSL
  • A staging certificate was left installed on the production vhost
  • CDN or Cloudflare proxy enabled for a hostname not on the origin certificate
  • Multisite or subdirectory-to-domain mapping added hosts without SAN updates
  • AutoSSL ran for one domain in the account but not the alias visitors use

Troubleshooting steps

  1. 01

    Compare the URL hostname to the certificate SAN list

    Open the certificate from the browser warning and list every DNS name. Write down the exact host you typed (including www vs apex and any shop/subdomain). The fix is covering those strings—not restarting PHP.

  2. 02

    Decide the canonical hostnames that must stay on HTTPS

    Pick the live set: apex, www, and any required subdomains (e.g. `shop.`). Update DNS and WordPress URL settings toward that set so you are not maintaining surprise hostnames that never get certificates.

  3. 03

    Reissue a certificate that includes every required SAN

    Use AutoSSL, Let’s Encrypt, or your CA portal to request a cert covering all chosen names (or a wildcard where appropriate and supported). Wait until validation succeeds for each name before calling the job done.

  4. 04

    Install the certificate on the correct vhost / Cloudflare origin

    Bind the new cert to the site’s virtual host or load-balancer listener. On Cloudflare, ensure custom hostnames or origin certs match what Full (strict) expects. Remove leftover staging certificates from the production server block.

  5. 05

    Align redirects so users only hit covered hostnames

    After the cert is valid, keep a single HTTP→HTTPS and apex↔www policy that lands on a hostname present in the SAN list. A redirect to an uncovered host recreates the mismatch instantly.

  6. 06

    Retest each hostname from a private window

    Load https for apex, www, and critical subdomains. Confirm the padlock shows the new certificate names and that WordPress admin and checkout follow the same host.

When to stop troubleshooting

Escalate if the host panel will not let you add SANs, DNS for validation is controlled by another party, a reverse proxy you cannot configure keeps presenting the wrong cert, or ecommerce is down across multiple hostnames and you lack access to both Cloudflare and origin SSL. Provide the requested hostname, the SAN list from the failing certificate, and where DNS currently points.

Information to collect before requesting help

  • 01 Exact hostname in the address bar when the warning appears
  • 02 SAN / CN list from the presented certificate
  • 03 Whether apex, www, and subdomains behave differently
  • 04 Certificate issuer and where it is managed (host, Cloudflare, external CA)
  • 05 Recent domain, DNS, or migration changes
  • 06 Cloudflare proxy status and SSL/TLS mode, if any
  • 07 WordPress Address / Site Address values

How a professional repairs the problem

We inventory every hostname that must work, reissue a certificate with matching SANs, correct vhost or Cloudflare origin binding so the right cert is served, and align redirects and WordPress URLs to those names. We verify apex, www, admin, and checkout on HTTPS before closing the mismatch.

Frequently asked questions

Is a name mismatch the same as an expired certificate? +
No. Expiry fails the date check (often NET::ERR_CERT_DATE_INVALID). A name mismatch fails the hostname check even when dates are still valid.
Why does www work but the bare domain does not? +
The certificate likely lists only one of them. Reissue with both names (or redirect permanently to the single covered hostname after the cert matches that choice).
Can I just ignore the warning for my own admin work? +
Do not train yourself—or customers—to click through identity failures. Fix the SAN list; mismatches are indistinguishable from some attack scenarios to a normal visitor.
Does installing any Let’s Encrypt cert fix the mismatch? +
Only if validation includes every hostname you need. A successful issue for the wrong name (or only the old domain) still leaves the mismatch on the URL people type.
Will changing WordPress siteurl alone fix this? +
URL settings can stop sending people to an uncovered host, but if they still open the uncovered hostname directly, HTTPS will fail until that name is on the certificate or redirects away before TLS to that host is required.
How is this different from “Not secure” mixed content? +
Mixed content usually means the main page already has a valid cert but some assets load over HTTP. A name mismatch blocks or warns on the document’s own certificate identity before mixed-content cleanup matters.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.