# ERR_CERT_COMMON_NAME_INVALID on cPanel: Wrong Certificate Served

Source: https://srvscripts.com/guides/cpanel-err-cert-common-name-invalid/
Updated: 2026-10-06
Publisher: srvScripts (https://srvscripts.com/)

**Short answer:** ERR_CERT_COMMON_NAME_INVALID means the browser received a certificate that does not list the name it asked for. On cPanel the usual causes are DNS (or an AAAA record) pointing at an IP where the site has no SSL virtual host, AutoSSL not covering that name (often `www`), visitors opening `https://example.com:2083` instead of `https://cpanel.example.com`, or a proxy in front serving its own certificate. Test with `openssl s_client -connect IP:443 -servername example.com` to see exactly which certificate each IP and port returns.

We ran these commands on our lab server (AlmaLinux 9.8, cPanel & WHM 11.138, OpenSSL 3.5.8) on 6 October 2026. Output below is from that run with domain names replaced by example names.

## What the browser is telling you

During the TLS handshake the browser sends the hostname it wants (SNI). The server picks a certificate and sends it. If neither the certificate’s subject nor its Subject Alternative Names (SANs) contain that hostname, Chrome shows `NET::ERR_CERT_COMMON_NAME_INVALID`; Firefox shows `SSL_ERROR_BAD_CERT_DOMAIN`. The certificate is usually valid; it is just the wrong one for that name. So the job is to find out which certificate is served, and why.

## Step 1: see which certificate is served

Run this from your workstation or from the server. It connects to one IP and port, sends one name, and prints the certificate’s subject, SANs and expiry:

```
IP=203.0.113.10
NAME=example.com
echo | openssl s_client -connect $IP:443 -servername $NAME 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName -enddate
```

On our lab, asking the server’s main IP for a cPanel account’s domain returned the AutoSSL certificate for that account. Note that the SAN list already includes cPanel’s service subdomains:

```
subject=CN=example.com
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:cpanel.example.com,
DNS:webmail.example.com, DNS:webdisk.example.com, DNS:cpcontacts.example.com,
DNS:cpcalendars.example.com, DNS:autodiscover.example.com, DNS:autoconfig.example.com
notAfter=Oct  5 19:33:08 2027 GMT
```

Now repeat the test with the exact IP the visitor reaches. Check both address families, because browsers prefer IPv6 when an AAAA record exists:

```
dig +short A example.com
dig +short AAAA example.com
curl -svI https://example.com/ --resolve example.com:443:203.0.113.10 2>&1 | grep -E "subject:|subjectAltName|SSL certificate"
```

## Cause 1: the name points at the wrong IP or listener

If DNS sends the visitor to an IP where Apache has no SSL virtual host for that domain, Apache answers with the default certificate for that IP, which on cPanel is usually the server hostname certificate. Our lab shows this clearly. The same request sent to the loopback address, where no account virtual host listens, came back with the hostname certificate:

```
# servername=example.com, but connected to 127.0.0.1:443
subject=CN=server1.example.net
```

Common real-world versions of the same mistake:

- An AAAA record points to the server’s IPv6 address, but the account only has an IPv4 virtual host. IPv4 users are fine; IPv6 users get the error.

- The account was moved to a dedicated IP (or back to the shared IP) and DNS still points to the old one.

- After a migration, the domain still resolves to the old server, which has a different or no certificate for it.

Fix DNS (or remove the stale AAAA record), or assign the account’s IPv6 address in WHM so a matching virtual host exists. Then repeat the `openssl` test on each IP.

## Cause 2: AutoSSL does not cover that name

If the right IP serves a certificate for `example.com` but the visitor typed `www.example.com` or an addon or parked domain, check the SAN list. A name drops out of AutoSSL when domain control validation fails for it (DNS not pointing to the server, a CAA record that excludes the provider, a CDN in the way). Run AutoSSL for the account and read its log:

```
/usr/local/cpanel/bin/autossl_check --user=bob
```

The command does one AutoSSL check for that user (or `--all`). In WHM, **SSL/TLS > Manage AutoSSL > Logs** lists which names failed validation and why. Our [AutoSSL DCV guide](/guides/autossl-failed-cpanel-dcv-caa-cdn/) covers the fixes, and the [AutoSSL failure report script](/scripts/autossl-failure-report/) lists failures for every account.

## Cause 3: panel ports and service subdomains

cPanel’s own services choose certificates differently from Apache. On our lab, the cPanel login port behaved like this:

| Request | Certificate returned |
| --- | --- |
| cpanel.example.com on port 2083 | The account’s certificate (CN=example.com) |
| webmail.example.com on port 2096 | The account’s certificate (CN=example.com) |
| example.com on port 2083 | The server hostname certificate |

So a customer who bookmarks `https://example.com:2083` gets ERR_CERT_COMMON_NAME_INVALID, while `https://cpanel.example.com:2083` works. With service subdomains (proxy subdomains) enabled, which they were on our lab, `https://cpanel.example.com/` on port 443 works too. Tell customers to use either the service subdomain or the server hostname, for example `https://server1.example.net:2083`.

cPanel’s own service certificates (cpsrvd, Dovecot, Exim, FTP) can be checked from the shell. Note that on our lab `checkallsslcerts` ignored `--help` and ran the check straight away:

```
/usr/local/cpanel/bin/checkallsslcerts
```

## Cause 4: mail clients and mail.example.com

Mail clients raise the same error as a certificate warning when they connect to `mail.example.com` on ports 993, 995, 465 or 587. On our lab, IMAPS and SMTPS answered `mail.example.com` with the server hostname certificate, and `/etc/dovecot/sni.conf` listed only the hostname’s names. Two ways to deal with it:

- Point mail clients at the server hostname. Its certificate is always valid for that name.

- Rebuild the mail SNI map so Dovecot and Exim know the domain certificates. The script ships with cPanel; its help lists these options:

```
/usr/local/cpanel/scripts/build_mail_sni --help
#   --fix_ssl_perms
#   --rebuild_dovecot_sni_conf
#   --restartsrvs
/usr/local/cpanel/scripts/build_mail_sni --rebuild_dovecot_sni_conf --restartsrvs
```

`--restartsrvs` restarts Dovecot and Exim, which drops open IMAP sessions. Run it outside business hours and test with `openssl s_client -connect IP:993 -servername mail.example.com` afterwards.

## Cause 5: a proxy or CDN in front

If the domain goes through Cloudflare, another CDN, a load balancer or a WAF, the browser sees the proxy’s certificate, not cPanel’s. Test both legs separately:

```
# what visitors get (the proxy)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer
# what the origin serves (bypass the proxy)
echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer
```

If the visitor leg is wrong, fix the certificate at the proxy (for example, the hostname is not covered by the proxy’s edge certificate). If only the origin leg is wrong, fix cPanel with the steps above; a proxy set to validate the origin certificate will fail too.

## Cause 6: clients without SNI and manual installs

- **No SNI:** a client that sends no name gets the first SSL virtual host on that IP. On our lab, a request without SNI to the main IP returned the first account’s certificate. Modern browsers always send SNI; old scripts, monitoring tools or embedded devices may not.

- **Manual certificate for the wrong name:** someone installed a certificate in **SSL/TLS > Manage SSL sites** that covers `example.com` but not `www`, and AutoSSL will not replace a valid manual certificate by default. Remove it or replace it with one that covers all names.

## Check that it worked

```
for ip in 203.0.113.10 2001:db8::10; do
  for n in example.com www.example.com; do
    printf "%s %s -> " "$ip" "$n"
    echo | openssl s_client -connect "[$ip]:443" -servername $n 2>/dev/null | openssl x509 -noout -subject
  done
done
```

Every combination should return a certificate whose SANs include the name. Then load the site in a private browser window over both IPv4 and IPv6 networks if you can. Our [SSL certificate checker](/tools/ssl-certificate-checker/) shows the chain and SANs from outside.

**Official documentation:** [OpenSSL s_client manual](https://docs.openssl.org/3.5/man1/openssl-s_client/) · [cPanel: Manage AutoSSL](https://docs.cpanel.net/whm/ssl-tls/manage-autossl/)

**Related:** [AutoSSL Failed cPanel: Fix DCV, CAA and CDN Problems](/guides/autossl-failed-cpanel-dcv-caa-cdn/) · [cPanel Hostname SSL: Let’s Encrypt AutoSSL Fix in WHM](/guides/cpanel-hostname-ssl-lets-encrypt/) · [cPanel SSL/TLS Interface (v136+): Install and Renew](/guides/cpanel-ssl-tls-interface-136/) · [SSL Certificate Checker](/tools/ssl-certificate-checker/) · [AutoSSL DCV Failures Report](/scripts/autossl-failure-report/)

**See also:** [Let’s Encrypt Changes 2025 to 2028: What Hosting Admins Must Do](/guides/lets-encrypt-2026-changes/) · [200-Day SSL Certificates and DCV Reuse: What It Means for AutoSSL](/guides/ssl-200-day-dcv-reuse/)

## Frequently asked questions

### What causes ERR_CERT_COMMON_NAME_INVALID?

The server sent a certificate that does not list the hostname in the address bar. The certificate is usually valid, just for a different name.

### Why does https://example.com:2083 show a certificate error?

On cPanel the login port serves the server hostname certificate for the bare domain. Use cpanel.example.com or the server hostname instead.

### Why do only some visitors see the error?

Often an AAAA record: IPv6 visitors reach an address without a matching SSL virtual host and get the hostname certificate.

### Does AutoSSL cover www automatically?

It tries to, but www is dropped if domain control validation fails for it. Check the AutoSSL log for that user.

### How do I check which certificate a server sends?

Use openssl s_client with -connect IP:port and -servername NAME, then pipe to openssl x509 -noout -subject -ext subjectAltName.