How to fix an SSL certificate with the wrong hostname or subdomain

What a hostname mismatch error means

When a browser connects over HTTPS it asks the server for a certificate, then checks three things: that the certificate was issued by an authority it trusts, that it is in date, and that it was issued for the hostname being visited. A mismatch error means the first two checks passed but the third failed. The certificate is genuine, it is simply for a different name.

The name check uses the Subject Alternative Name (SAN) list inside the certificate. The older Common Name field is ignored by Chrome, Edge, Firefox and Safari, so a certificate with CN=example.com and no SAN entries fails even on example.com. Every hostname you serve must appear in the SAN list, either exactly or through a wildcard.

Because the error is about names, it is very common for one address to work and another to fail on the same site. https://example.com loads, while https://www.example.com or https://shop.example.com shows the warning. That pattern tells you the certificate itself is fine and the fix is to cover the missing name or to send the right certificate for it. If instead every hostname fails with an authority or date error, see fixing an untrusted certificate.

Why the certificate does not match

Almost every mismatch comes from one of a small number of causes. Find yours before changing anything, because the fix for a missing SAN is different from the fix for a server that sends the wrong certificate.

How wildcards really behave

A wildcard covers exactly one label in the leftmost position. *.example.com matches www.example.com and shop.example.com, but not example.com itself and not dev.shop.example.com. Most certificate authorities, including Let's Encrypt, add the bare domain alongside the wildcard if you ask for both names, which is what you normally want.

How to see which names your certificate covers

In Chrome, click the icon to the left of the address, choose the connection details, then open the certificate viewer and look at the Subject Alternative Name field under Details. That shows you what the browser received, which may not be the certificate you think you installed.

From a terminal, OpenSSL tells you exactly what the server sends for a given name. The -servername option sets SNI, the field the server uses to choose a certificate, so always set it to the hostname that fails:

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Typical output for a certificate that is missing www:

subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R11
notBefore=Sep  2 08:14:21 2026 GMT
notAfter=Dec  1 08:14:20 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com

Only one name is listed, so www.example.com cannot pass. If the SAN list shows a completely different domain, such as the host's server name, the server is falling back to its default certificate because no HTTPS site is set up for the name you asked for.

Quick checks with curl and DNS

curl -vI https://www.example.com 2>&1 | grep -Ei "subject|issuer|SSL"
dig +short www.example.com
dig +short example.com

Compare the two DNS answers. If www is a CNAME to a platform or resolves to an older IP address, the certificate you installed on your main server is never reached. You can also run the hostname through the security audit, which reports the names on the certificate and whether the visited host is among them.

Issuing a certificate that covers every name

Make a list of every hostname a visitor or crawler might use: the bare domain, www, each subdomain, and any extra domains that redirect to the main one. Every name on that list needs a valid certificate, including the ones that only redirect.

Certbot on your own server

Issue one certificate for both the bare domain and www, using the nginx or Apache plugin so the configuration is updated for you:

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot --apache -d example.com -d www.example.com

To add a subdomain to an existing certificate, run the command again with the full list of names plus --expand. Certbot replaces the certificate with one that carries all the names:

sudo certbot --nginx --expand -d example.com -d www.example.com -d shop.example.com
sudo certbot certificates

The second command lists every certificate on the server and the names it covers, which is a quick way to confirm the change.

Wildcards need the DNS challenge

Let's Encrypt only issues wildcard certificates through the DNS-01 challenge, where you prove control by adding a TXT record at _acme-challenge.example.com. Use a Certbot DNS plugin for your DNS provider so renewals are automatic; a manual TXT record works once but will not renew on its own.

sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d "*.example.com"

Making the server send the right certificate

Most servers host several sites on one IP address and pick the certificate using SNI, the hostname the browser sends at the start of the TLS handshake. If no HTTPS site claims that name, the server sends its default certificate, and you get a mismatch even though the right certificate is installed somewhere on the machine.

nginx

The name must appear in server_name inside a block that listens on 443:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Run sudo nginx -t and then sudo systemctl reload nginx. On older nginx versions the http2 setting goes on the listen line instead.

Apache

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

A common mistake is adding the alias only to the port 80 virtual host. Run sudo apachectl -S to list which virtual host answers each name on port 443.

Plesk, cPanel and Cloudflare

• Plesk. Open the domain, choose SSL/TLS Certificates, and reissue the Let's Encrypt certificate with the www option ticked. Subdomains are separate entries in Plesk and need their own certificate unless you choose the wildcard option.
• cPanel. AutoSSL covers the domain, www and subdomains that resolve to the server. Run AutoSSL again after adding a subdomain, and check the excluded names list.
• Cloudflare. The free Universal SSL certificate covers the bare domain and one level of subdomain. A name like dev.shop.example.com needs an extra edge certificate. Names set to DNS only skip Cloudflare entirely, so your server must hold a valid certificate for them. See Cloudflare redirects for the related redirect settings.

Worked example: www and a shop subdomain

Example Bakery runs example.com on an nginx server with a Let's Encrypt certificate. The main address loads fine, but visitors who type www.example.com see NET::ERR_CERT_COMMON_NAME_INVALID, and a new shop at shop.example.com shows the same error.

1. OpenSSL against www.example.com shows DNS:example.com as the only SAN. The www name was never requested.
2. OpenSSL against shop.example.com returns a certificate for the hosting company's server name. There is no nginx block with server_name shop.example.com on port 443, so the default certificate is sent.
3. DNS for both names points at the same server, so the HTTP-01 challenge can work for both.
4. The owner adds a 443 server block for the shop, then runs certbot --nginx --expand -d example.com -d www.example.com -d shop.example.com.
5. certbot certificates now lists all three names, and OpenSSL against each host shows the full SAN list.
6. Finally the www block is set to return a 301 to https://example.com, so there is one main address, as covered in www canonicalisation.

Total time was about twenty minutes, and the renewal job now covers all three names together.

The fix, step by step

Edge cases worth knowing

• Old domains that only redirect. If example.co.uk redirects to example.com, it still needs its own valid certificate, or HTTPS visitors and crawlers stop at the warning before the redirect is read.
• Hosted platforms. When www is a CNAME to a site builder or shop platform, the platform issues the certificate. Add the custom domain in the platform's settings and wait for it to show as active; installing a certificate on your own server does nothing for that name.
• Mail and panel addresses. mail.example.com, webmail and the control panel address are hostnames too. In Plesk, tick the option to secure webmail when you issue the certificate if you use it.
• HSTS with includeSubDomains. If your main site sends HSTS with includeSubDomains, every subdomain must have a valid certificate, and browsers will not let visitors click past the warning. See HSTS errors.
• Windows servers. IIS needs a binding per hostname with SNI ticked, as described in IIS SSL bindings.

Keeping every hostname covered

Most mismatches come back when someone adds a subdomain or changes DNS months later. Keep a short list of every hostname in use, and whenever you add one, expand the certificate in the same change. Check renewals with sudo certbot renew --dry-run, because one name that no longer points at the server can fail the whole certificate.

Run the hostnames through the security audit after any DNS or hosting change, and test with OpenSSL using -servername for each name, not just the main one. If the site loads with a padlock but still says not secure, the problem has moved on to a certificate that is installed but not working, which is usually mixed content or a missing redirect.