Wildcard Certificates for Multi-Subdomain Scenarios: Coverage, Limitations, and When to Switch

As the number of subdomains grows, signing individual domain certificates becomes a burden: each new subdomain requires a new signature and configuration. A wildcard certificate covers all peer-level subdomains at once, eliminating this repetitive work.

However, it has clear limitations. Using it in the wrong scenario wastes money.

What Wildcards Cover

Wildcard: *.example.com

Covers:
  ✓ api.example.com
  ✓ www.example.com
  ✓ img.example.com
  ✓ Any single-level subdomain

Does NOT cover:
  ✗ example.com (the root domain)     ← Most common misconception
  ✗ a.b.example.com (multi-level subdomain)
  ✗ other.com (different domains)

# Verify certificate coverage (check SAN)
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -ext subjectAltName

# A wildcard certificate should display something like: DNS:*.example.com

The Root Domain Must Be Covered Separately

Many people assume *.example.com includes example.com, but it does not.

# Correct approach: Include both in the SAN
# You should see two lines when checking:
#   DNS:*.example.com
#   DNS:example.com

If the root domain also needs HTTPS (which is usually required), you must include both the root domain and the wildcard in the SAN during issuance, or: use the wildcard for the www subdomain and redirect the root domain to www.

# Option 2: Redirect root domain to www (www is covered by wildcard)
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /path/wildcard-fullchain.pem;
    ssl_certificate_key /path/wildcard-key.pem;
    return 301 https://www.example.com$request_uri;
}

Note: Even if it’s just a redirect, this server block still needs a certificate (the HTTPS handshake occurs before the redirect). The good news is that wildcards can cover redirection needs outside the root domain—but if the root domain is not in the SAN, users visiting https://example.com will first see a certificate warning, and the redirect will never happen.

Therefore, the safest approach is: include both the root domain and the wildcard in the SAN.

When to Switch to a Wildcard

Criterion: Look at “will subdomains be added in the future”, not just how many exist now. If you have two now but might have five next year, use a wildcard.

Steps for Replacement

# ① Issue wildcard certificate (ensure SAN includes root domain and *.domain)
# With acme.sh, DNS validation supports wildcards
acme.sh --issue -d example.com -d '*.example.com' --dns dns_xxx

# ② Install on server (use fullchain)
acme.sh --install-cert -d example.com 
  --key-file       /etc/nginx/ssl/example.com/privkey.pem 
  --fullchain-file /etc/nginx/ssl/example.com/fullchain.pem 
  --reloadcmd      "nginx -s reload"

# ③ Update site configurations to point to the new certificate
grep -rl 'old_cert_path' /etc/nginx/conf.d/ 
# Replace one by one

# ④ Validate and reload
nginx -t && nginx -s reload

Wildcards Require DNS Validation

This is a key limitation: wildcard certificates cannot be issued via file validation (HTTP-01); they must use DNS validation (DNS-01).

# DNS validation requires API permissions from your DNS provider
# Different DNS providers correspond to different dns_xxx parameters
acme.sh --issue -d example.com -d '*.example.com' --dns dns_ali
# Requires configuring the corresponding API key

This also means automatic renewal relies on the DNS provider’s API. If API credentials expire or permissions change, renewal will fail—so monitor whether renewals succeed.

# Confirm renewal task exists
crontab -l | grep acme

# Check renewal logs
tail -50 ~/.acme.sh/acme.sh.log

Verification (Test Every Subdomain)

# Verify each covered subdomain individually
for d in api img static www; do
  echo -n "$d.example.com  "
  openssl s_client -connect $d.example.com:443 -servername $d.example.com 
    -verify_return_error </dev/null 2>/dev/null | grep -i 'verify return'
done
# Each should return: Verify return code: 0 (ok)

# Confirm the certificate is indeed a wildcard
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -ext subjectAltName | grep -o '*.'

Decision Tree

Should I use a wildcard?
├─ Will subdomains continue to increase?
│  └─ Yes → Wildcard
├─ Are there many subdomains (5+)?
│  └─ Yes → Wildcard
├─ Are there multi-level subdomains?
│  └─ Yes → Wildcard is insufficient; sign separately
└─ After deciding to use a wildcard:
   ├─ SAN must include both root domain and *.domain ← Easiest to miss
   ├─ Must use DNS validation (file validation not supported)
   ├─ Check DNS API credentials and renewal monitoring
   └─ Verify chain completeness for every subdomain

Scenario Walkthrough: The Domain Not Covered by the Wildcard

Symptom: Purchased and deployed a wildcard certificate.
Most subdomains work normally. But one specific subdomain consistently reports a certificate error.

1. First, check if the error points to a domain mismatch or incomplete chain →
   If the prompt says “name mismatch,” it means the domain is not covered by this certificate.
2. Confirm the wildcard’s coverage boundary →
   It only matches single-level subdomains; multi-level subdomains are out of scope. This issue involves a multi-level form.
3. List all domains that actually need coverage →
   List current and potential future domains, and verify them against the boundary one by one.
4. Determine a supplementary solution →
   Multi-level forms require a separate certificate or one that lists these specific domains.
5. Issue and deploy the supplementary part →
   It coexists with the main certificate. Note that the expiration times of both sets must be monitored.
6. Verify coverage for each domain individually →
   Do not sample; test every item on the list.

# See which domains this certificate actually covers
echo | openssl s_client -connect a.example.com:443 -servername a.example.com 2>/dev/null 
  | openssl x509 -noout -ext subjectAltName

# Verify one by one (focus on multi-level forms)
for h in a.example.com admin.example.com a.b.example.com; do
  printf '%-28s ' "$h"
  echo | openssl s_client -connect $h:443 -servername $h -verify_return_error 2>&1 
    | grep -o 'Verify return code: [0-9]*'
done

# Monitor expiration times for all (the supplementary cert is a separate one)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -enddate

Root Cause: Misconception that wildcards can cover subdomains of any depth.
It only matches one level; multi-level forms require separate coverage.

Two Key Takeaways:

• Wildcards only cover single-level subdomains; multi-level forms must be handled separately.
  This is the most common mistake during selection, and errors only surface on specific domains.
• The supplementary certificate is a separate entity; its expiration time must be monitored independently.
  Two sets of certificates mean two sets of operations. Focusing only on the main certificate allows the supplementary one to expire silently.

8 Common Pitfalls

1. Assuming wildcards include the root domain: They don’t; it must be written into the SAN separately.
2. Assuming they cover multi-level subdomains: They only cover single-level.
3. Using file validation for wildcards: Not supported; DNS validation is mandatory.
4. DNS API credentials expiring: Renewal fails silently.
5. Changing certificates without updating all site configs: Some sites still use the old ones.
6. Testing only one subdomain: Every one must be verified.
7. Using cert instead of fullchain: Incomplete chain.
8. Redirecting the root domain without a certificate: Handshake fails before the redirect.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar O&M services on Alibaba Cloud, Tencent Cloud, and Huawei Cloud cloud markets (service providers include our store and peers, provided for reference only, not fictional tickets from this site):

a****8 Rating: 5.0 2025-08-22 14:43 r****8 Rating: 5.0 2025-05-22 15:34 t****c Rating: 5.0 2025-04-18 13:58 Cai****Kang Rating: 5.0 2024-08-31 12:05 2****2 Rating: 5.0 2024-02-21 11:08

s****2 Rating: 5.0 2023-02-28 11:04 Mai****8 Rating: 5.0 2020-06-29 17:44 4****6 Rating: 5.0 2019-01-07 14:56