Wildcard certificates: what *.example.com actually covers
2 min read
Bought a wildcard but some addresses are still untrusted? *.example.com covers neither the bare domain nor second-level subdomains. The one-level rule, examples and fixes.
The one-level rule
The asterisk in *.example.com matches exactly one label. So www.example.com, api.example.com and mail.example.com are covered; but example.com (the bare domain — there is no label for the asterisk to fill) and test.api.example.com (two levels) are not. This is standard behaviour defined in RFC 6125, and every browser follows it.
The most common surprise is the bare domain: the wildcard goes live and visitors to example.com hit a warning. The fix is simple: include example.com as an extra SAN entry — modern CAs issue wildcard + bare name in the same certificate.
Diagnosis
Query the exact failing address in SSLx. The match dialog knows the wildcard rule and states the reason plainly: "a wildcard covers subdomains but not the bare name" or "a wildcard covers only ONE level; this name is deeper".
Deep subdomains
For names like a.b.example.com you have two options: add that exact name to the SAN list, or obtain a nested wildcard such as *.b.example.com. A "double wildcard" (*.*.example.com) does not exist; no browser accepts it.
Test your own site
SSLx performs every diagnosis in this guide in ten seconds: chain verification, hostname matching, expiry and HSTS — free, no signup.
Test with SSLxFrequently asked questions
Are wildcard certificates a security risk?
Their broad scope means a leaked key affects every subdomain — so keep the key on as few servers as possible, or prefer per-name certificates. Stored properly, the cryptography is just as strong.
Does Let's Encrypt issue wildcards?
Yes, but only via DNS-01 validation: you must be able to add a temporary TXT record to the domain's DNS.