Fix NET::ERR_CERT_COMMON_NAME_INVALID: Wildcard SSL for Multi-Level Subdomains

The ProblemImagine you just deployed a new microservice at sub.api.example.com. Your wildcard SSL for *.example.com works perfectly for api.example.com and web.example.com, so you expect it to handle this new URL too. Instead, the browser throws a privacy warning and blocks the connection.

Chrome users will see this specific error:

NET::ERR_CERT_COMMON_NAME_INVALID: *.example.com does not cover sub.api.example.com

This is a common headache when scaling architectures. You might hit this wall while setting up dedicated staging environments, such as dev.api.example.com, assuming your existing certificate is a catch-all solution.

The Root CauseWildcards are not recursive. According to SSL/TLS specifications (RFC 6125), a wildcard character (*) only protects one single level of the subdomain hierarchy. It cannot "see" through dots.

• *.example.com validates one.example.com- *.example.com validates two.example.com- *.example.com FAILS for sub.one.example.comThink of it as the "One Dot Rule." When a browser encounters sub.api.example.com, it searches for a certificate explicitly covering that fourth level, such as *.api.example.com or the exact FQDN.

Debug ProcessVerify exactly what your server is sending before you start changing configurations. You can pull the certificate details directly from your terminal using openssl:

openssl s_client -connect sub.api.example.com:443 -servername sub.api.example.com | openssl x509 -text -noout | grep -A 1 "Subject Alternative Name"

Check the output. If you only see DNS:*.example.com, DNS:example.com, your certificate is technically invalid for the requested URL. The browser is right to complain; the Subject Alternative Name (SAN) simply doesn't cover the fourth-level domain.

The Solutions### Option 1: Issue a Nested Wildcard (Best for Scaling)If you plan to host multiple sub-subdomains like client1.api.example.com and client2.api.example.com, you need a certificate that covers that specific level. You can actually bundle multiple wildcard levels into one certificate.

Using Certbot with a DNS-01 challenge, run this command to cover the base, the first level, and the second level:

certbot certonly --manual --preferred-challenges dns \-d "example.com" \-d "*.example.com" \-d "*.api.example.com"

This generates a single .pem file. Note that your DNS provider will require you to create two distinct TXT records during this validation process.

Option 2: Use a Multi-Domain (SAN) CertificateMaybe you only have one or two outliers like billing.api.example.com. In that case, you don't need a nested wildcard. Simply add the specific FQDN to your existing certificate request.

Ensure your Certificate Signing Request (CSR) includes these entries in the SAN field:

• example.com- *.example.com- billing.api.example.com### Option 3: Flatten Your DNS StructureSometimes the smartest fix is architectural. Can you change sub.api.example.com to sub-api.example.com? By replacing the dot with a hyphen, you move the subdomain back to the third level. Your original *.example.com certificate will then cover it perfectly without any extra cost or configuration.

Updating the Web ServerAfter obtaining your new certificate, point your web server configuration to the updated files and reload the service.

Nginx Example```

server { listen 443 ssl; server_name sub.api.example.com;

ssl_certificate /etc/letsencrypt/live/api-combined/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/api-combined/privkey.pem;

}

### Apache Example```
<VirtualHost *:443>
    ServerName sub.api.example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/api-combined.crt
    SSLCertificateKeyFile /etc/ssl/private/api-combined.key
</VirtualHost>

VerificationRestart your web server (e.g., systemctl restart nginx) and test the connection with curl. The -v flag provides a detailed look at the SSL handshake.

curl -vI https://sub.api.example.com

Search the output for SSL certificate verify ok. If the error persists, the server might still be caching the old certificate or pointing to the wrong file path.

Lessons LearnedWildcard SSLs are great for flat structures but offer a false sense of security for complex DNS hierarchies. Keep these three rules in mind for your next project:

• The One Dot Limit: A wildcard covers exactly one level. No more, no less.- DNS-01 is Key: Use DNS challenges with Let's Encrypt to issue multi-level wildcard certificates easily.- Hyphens are Cheaper: Avoid deep subdomains if a hyphenated name achieves the same organizational goal.