ERR_CERT_COMMON_NAME_INVALID on cPanel: Wrong Certificate Served

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 covers the fixes, and the AutoSSL failure report script 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 shows the chain and SANs from outside.

Official documentation: OpenSSL s_client manual · cPanel: Manage AutoSSL

Related: AutoSSL Failed cPanel: Fix DCV, CAA and CDN Problems · cPanel Hostname SSL: Let’s Encrypt AutoSSL Fix in WHM · cPanel SSL/TLS Interface (v136+): Install and Renew · SSL Certificate Checker · AutoSSL DCV Failures Report

See also: Let’s Encrypt Changes 2025 to 2028: What Hosting Admins Must Do · 200-Day SSL Certificates and DCV Reuse: What It Means for AutoSSL

Frequently asked questions