Plesk SSL Name Mismatch Error: Complete Fix Guide (2026)

A Plesk SSL name mismatch error shows up when a visitor's browser flags "Your connection is not private" or "NET::ERR_CERT_COMMON_NAME_INVALID" on a site that Plesk is supposed to be securing. The root cause is almost always simple: the certificate installed doesn't cover the exact hostname the browser requested. This guide covers every place that mismatch can come from in Plesk, and exactly how to fix each one.

Why the Name Mismatch Happens

TLS certificates are issued for specific hostnames -- either an exact domain (example.com), a wildcard (*.example.com), or a list of Subject Alternative Names (SANs) covering multiple hosts. A mismatch occurs when the hostname in the browser's address bar isn't included anywhere in the certificate's Common Name or SAN list. In Plesk, this usually happens because of one of these situations:

• The certificate was issued for example.com but the site is being accessed at www.example.com (or vice versa)
• A subdomain (like mail.example.com or webmail.example.com) is using the main domain's certificate, which doesn't include it
• The domain was recently added or renamed in Plesk, and the SSL/TLS certificate binding wasn't updated to match
• A wildcard certificate exists but wasn't actually assigned to the new subdomain in the hosting settings
• Multiple sites share one IP with SNI misconfigured, causing the wrong certificate to be served for a given hostname

Step 1: Identify Exactly Which Hostname Is Mismatched

Run this from any machine with OpenSSL to see precisely what certificate is being served for a hostname:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

Compare the output's Subject and SAN list against the hostname you actually typed into the browser. If the domain you're visiting isn't listed anywhere in that output, you've confirmed the mismatch and know exactly which name is missing.

Step 2: Check the Certificate Assigned in Plesk

1. Log in to Plesk and go to Websites & Domains for the affected domain.

2. Click "SSL/TLS Certificates".

This shows every certificate uploaded for the domain and which one is currently marked as active for the main site, and separately for mail.

3. Confirm the active certificate's domain list. Click into the certificate to see its Common Name and SAN entries. If the hostname the visitor is using isn't listed, that certificate is the wrong one for this site.

Step 3: Reissue or Reassign the Correct Certificate

If you're using Plesk's built-in Let's Encrypt integration (the most common setup), the fix is usually a re-issue with the correct hostname list:

1. Go to SSL/TLS Certificates > Get a free certificate from Let's Encrypt.

2. Check every box for the domain names that need coverage -- this should include the bare domain, www, and any subdomains like mail. or webmail. that visitors actually use.

3. Include the wildcard option if you have many subdomains, so you don't have to reissue every time a new one is added.

4. Click "Get it free" and wait for Plesk to complete domain validation and installation.

If you're using a purchased certificate instead of Let's Encrypt, you'll need to either reissue it from your certificate authority with the correct SAN list, or purchase a certificate that actually covers the mismatched hostname, then upload and assign it under SSL/TLS Certificates.

Step 4: Fix Subdomain-Specific Mismatches

A very common cause is mail or webmail subdomains showing a mismatch even though the main site's SSL is fine. Plesk secures webmail and mail services using the domain's certificate by default, but only if that certificate explicitly includes the mail hostname:

1. Go to Tools & Settings > SSL/TLS Certificates (server-wide) or the domain-level equivalent.

2. Assign the correct certificate to Mail and Webmail separately if Plesk shows them as distinct services -- they don't always inherit the main site's certificate automatically.

3. Reissue with SANs covering mail.example.com and webmail.example.com explicitly if those services use dedicated subdomains.

Step 5: Verify SNI and Default Site Binding

If multiple domains share one IP and one is showing another domain's certificate, SNI (Server Name Indication) may be misconfigured, or a "default" site is capturing requests before the correct virtual host is matched. In Plesk:

• Check Tools & Settings > IP Addresses to confirm which certificate is set as the default for the shared IP
• Ensure the affected domain's hosting settings explicitly select its own certificate rather than inheriting a default
• Restart the web server (Apache/Nginx) after reassigning certificates so the new bindings take effect: plesk sbin nginxmng --reconfigure-all (or restart via Plesk's service management panel)

Step 6: Clear Browser and CDN Caches

Once the correct certificate is issued and bound, browsers and any CDN or proxy in front of the site (like Cloudflare) may still cache the old handshake. Test with a fresh incognito window and, if using a CDN, verify its SSL mode is set to "Full" or "Full (strict)" rather than a flexible mode that could reintroduce a mismatch between the CDN edge and the origin server.

For hosting providers managing SSL across many client domains at once, this class of certificate/binding error is one of the most common tickets we see. CloudHouse's server management team handles bulk SSL audits so mismatches like this get caught before a client notices the browser warning.

Step 7: Prevent Future Mismatches

To stop this recurring:

• Always issue certificates with SANs covering every hostname the site is actually reachable on, including www and any mail-related subdomains
• Enable Plesk's automatic Let's Encrypt renewal and monitor for renewal failures, since a failed renewal can silently fall back to an expired or mismatched certificate
• Document every subdomain added to a site and confirm its certificate coverage immediately, rather than assuming inheritance from the parent domain

Diagnosing Mismatches Caused by Reverse Proxies and Load Balancers

If the Plesk server sits behind a reverse proxy, CDN, or load balancer, the mismatch may not originate on the Plesk box at all. The proxy terminates SSL itself and re-encrypts (or doesn't) to the origin, and if the proxy's own certificate doesn't match the hostname, Plesk's correctly configured certificate never even gets checked. Confirm this by connecting directly to the origin server's IP with the correct SNI hostname and bypassing DNS/CDN, using --resolve with curl:

curl -v --resolve example.com:443:ORIGIN_IP https://example.com/

If the certificate looks correct when hitting the origin directly but wrong through the public hostname, the issue is upstream of Plesk -- in the CDN or proxy configuration -- and needs to be fixed there, not in Plesk's SSL/TLS Certificates panel.

Handling Mismatches After a Domain Migration

Domain migrations are one of the most common sources of this error. When a site moves to a new Plesk server, subscription, or IP, the previous certificate frequently doesn't get carried over correctly, or DNS still partially points to the old server during propagation, serving an outdated certificate to some visitors. After any migration:

• Reissue a fresh Let's Encrypt certificate on the new server immediately rather than assuming the old one transferred
• Check DNS propagation with a tool like dig +trace example.com from multiple locations to confirm all resolvers point to the new IP before declaring the migration complete
• Keep the old server's certificate and site active briefly during the DNS cutover window so any stragglers still see a valid (if outdated-location) certificate rather than a connection failure

Server-to-server migrations are exactly the kind of task where a small oversight -- like forgetting to reissue SSL on the destination -- turns into a wave of client-facing warnings. Our server migration team builds SSL reissuance into every migration checklist so this never gets missed.

Testing Your Fix Properly Before Declaring It Resolved

Don't rely on a single browser check. Use an external SSL testing tool (such as SSL Labs) against the public hostname to confirm the served certificate, chain, and SAN list are all correct from outside your own network. Internal DNS caching or a stale hosts file entry on your own machine can make a fix look successful locally when the public-facing certificate is still wrong for other visitors.

Frequently Asked Questions

What causes a Plesk SSL name mismatch error?

It happens when the certificate installed for a site doesn't include the exact hostname the browser is requesting -- commonly a missing www variant, an uncovered subdomain like mail or webmail, or a certificate that wasn't updated after a domain rename.

How do I fix an SSL mismatch on a Plesk mail subdomain?

Reissue the certificate through Plesk's Let's Encrypt integration and explicitly include the mail and webmail hostnames as Subject Alternative Names, then assign that certificate to the Mail and Webmail services in the domain's SSL/TLS settings rather than relying on inheritance from the main site.

Does a wildcard certificate fix all subdomain mismatches automatically?

A wildcard certificate covers all first-level subdomains of a domain, but it must still be explicitly assigned to each new subdomain's hosting settings in Plesk -- simply having a wildcard certificate uploaded doesn't automatically apply it everywhere.

Why does the mismatch appear only on some domains sharing the same IP?

This usually points to an SNI or default-certificate misconfiguration, where the web server serves the wrong certificate for a hostname because that domain isn't explicitly bound to its own certificate. Check the SSL/TLS default certificate under IP Addresses in Plesk and ensure each domain has an explicit assignment.

Will clearing my browser cache fix a genuine SSL name mismatch?

No -- clearing cache only helps if the certificate has already been corrected on the server. If the underlying certificate still doesn't cover the requested hostname, every browser (and every visitor) will continue to see the warning until the correct certificate is issued and bound in Plesk.