How to Fix NET::ERR_CERT_COMMON_NAME_INVALID for Wildcard SSL (2026)

When configuring multi-tenant SaaS applications, client staging subdomains, or regional portals in Pakistan, webmasters frequently purchase or issue a wildcard SSL certificate (*.yourdomain.pk), install it on their server, and assume all current and future subdomains will be automatically secured.

Instead, when visitors navigate to specific endpoints (such as https://app.staging.yourdomain.pk or the bare apex domain https://yourdomain.pk), Google Chrome and Firefox abruptly block the connection with:

Your connection is not private
NET::ERR_CERT_COMMON_NAME_INVALID
(The server presented a certificate that is not valid for this domain name)

This error does not mean the certificate has expired or is cryptographically untrusted; rather, it indicates a hostname mismatch between the browser’s address bar and the Subject Alternative Name (SAN) entries inside the X.509 certificate.

Under RFC 6125 standards, wildcard certificates have strict syntactic and hierarchical boundaries. In this troubleshooting manual, we dissect wildcard matching mechanics, resolve multi-level subdomain failures, and configure Nginx, Apache, and cPanel & WHM to eliminate common name mismatches.

---

1. RFC 6125 Wildcard Matching Rules Explained

A wildcard asterisk (*) can only match a single, contiguous DNS label:

Certificate Issued For: *.yourdomain.pk

┌───────────────────────────────────────┬──────────────┬──────────────────────────────────────────┐
│ Requested URL in Browser              │ SSL Status   │ Explanation                              │
├───────────────────────────────────────┼──────────────┼──────────────────────────────────────────┤
│ https://blog.yourdomain.pk            │ 200 OK (Padlock)│ Matches single-level wildcard label      │
│ https://shop.yourdomain.pk            │ 200 OK (Padlock)│ Matches single-level wildcard label      │
│ https://yourdomain.pk (Apex Root)     │ ✖ MISMATCH!  │ Wildcard DOES NOT cover apex base domain!│
│ https://dev.app.yourdomain.pk         │ ✖ MISMATCH!  │ Wildcard CANNOT span multiple dots (.)   │
└───────────────────────────────────────┴──────────────┴──────────────────────────────────────────┘

The Two Most Common Wildcard Traps:

1. The Apex / Root Domain Exclusion: An SSL certificate issued strictly for *.yourdomain.pk will never validate the bare apex domain yourdomain.pk. The certificate MUST explicitly include both yourdomain.pk and *.yourdomain.pk in its Subject Alternative Name list.
2. Multi-Level Subdomains: *.yourdomain.pk only matches one dot level down. A subdomain like api.v1.yourdomain.pk requires either its own dedicated certificate or a nested wildcard (*.v1.yourdomain.pk).

---

2. Inspecting Live SAN Entries via OpenSSL CLI

Diagnose the exact list of domain names embedded inside your server’s active SSL certificate:

echo | openssl s_client -connect yourdomain.pk:443 -servername yourdomain.pk 2>/dev/null \
    | openssl x509 -noout -text | grep -A 3 "Subject Alternative Name"

Sample output:

X509v3 Subject Alternative Name:
    DNS:*.yourdomain.pk

If DNS:yourdomain.pk is missing from the SAN list above, navigating to https://yourdomain.pk will trigger NET::ERR_CERT_COMMON_NAME_INVALID.

---

3. Issuing a Fully Compliant Wildcard Certificate with Certbot

To issue a wildcard certificate via Let’s Encrypt that covers both the apex root and all subdomains, you must use DNS-01 validation (since HTTP-01 file validation cannot prove ownership of arbitrary future subdomains).

# Issue Let's Encrypt Wildcard covering BOTH apex and wildcard subdomains
certbot certonly --manual --preferred-challenges dns \
    -d "yourdomain.pk" \
    -d "*.yourdomain.pk"

Certbot will output a _acme-challenge.yourdomain.pk TXT record token. Add this TXT record to your authoritative DNS zone in cPanel, Cloudflare, or PowerDNS, wait 60 seconds for DNS propagation, and press Enter.

Inspect the newly generated certificate to verify dual SAN coverage:

openssl x509 -in /etc/letsencrypt/live/yourdomain.pk/cert.pem -noout -text \
    | grep -A 2 "Subject Alternative Name"

Output:

X509v3 Subject Alternative Name:
    DNS:yourdomain.pk, DNS:*.yourdomain.pk

---

4. Configuring Nginx Virtual Hosts for Wildcard SSL

In Nginx, avoid assigning a wildcard certificate to a default server block that also catches unconfigured domains, as this causes SNI mismatches for other client sites:

# 1. Apex Domain Configuration
server {
    listen 443 ssl http2;
    server_name yourdomain.pk;

    ssl_certificate /etc/letsencrypt/live/yourdomain.pk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.pk/privkey.pem;

    root /var/www/yourdomain.pk/html;
    index index.php index.html;
}

# 2. Wildcard Subdomain Catch-All Configuration
server {
    listen 443 ssl http2;
    server_name *.yourdomain.pk;

    ssl_certificate /etc/letsencrypt/live/yourdomain.pk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.pk/privkey.pem;

    root /var/www/subdomains/$host/html;
    index index.php index.html;
}

Verify and reload:

nginx -t && systemctl reload nginx

---

5. Installing Wildcard Certificates in cPanel & WHM

If managing multi-tenant SaaS clients or agency accounts on Dedicated Servers in Pakistan:

1. Log into cPanel for the target account.
2. Navigate to: Security >> SSL/TLS >> Install and Manage SSL for your site (Manage SSL Sites).
3. In the Domain dropdown, select yourdomain.pk.
4. Paste the CRT and Private Key.
5. In the Domains list underneath, ensure that both yourdomain.pk and *.yourdomain.pk appear with green checkmarks.
6. Click Install Certificate.
7. If cPanel SNI proxying is enabled, restart cpsrvd:

   /scripts/restartsrv_cpsrvd

---

6. SAN Validation Comparison Matrix

Hostname Requested	Certificate SAN Coverage	Handshake Result
https://yourdomain.pk	*.yourdomain.pk	FAIL (ERR_CERT_COMMON_NAME_INVALID)
https://yourdomain.pk	yourdomain.pk, *.yourdomain.pk	SUCCESS (Green Padlock)
https://billing.yourdomain.pk	*.yourdomain.pk	SUCCESS (Green Padlock)
https://dev.api.yourdomain.pk	*.yourdomain.pk	FAIL (Multi-level dot unhandled)
https://dev.api.yourdomain.pk	*.api.yourdomain.pk	SUCCESS (Dedicated Sub-Wildcard)

For additional SSL hardening protocols, explore our guides on How to Fix NET::ERR_CERT_AUTHORITY_INVALID in Enterprise Networks, How to Fix SEC_ERROR_REUSED_ISSUER_AND_SERIAL in Firefox, and How to Fix ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY.

Hosting your multi-tenant SaaS infrastructure on enterprise Dedicated Servers ensures flawless SSL handshakes and zero downtime.