Wildcard Certificates: What They Cover and Where They Fail
A wildcard certificate is often sold, and understood, as "one certificate to cover every subdomain," which is close enough to true to be useful but not quite precise enough to avoid real, occasionally confusing gaps in coverage. Understanding exactly what pattern a wildcard certificate matches — and what it deliberately doesn't — prevents a specific, recurring category of "why isn't my subdomain secured" support ticket.
What a Wildcard Certificate Actually Matches
A wildcard certificate, denoted with an asterisk in its common name (like *.example.com), covers any single-level subdomain of the base domain — www.example.com, shop.example.com, blog.example.com, and any other single additional label prepended to the base domain, all validated by exactly one certificate. This is genuinely useful for organizations running many subdomains, since it eliminates the need to issue, install, and separately renew a distinct certificate for each one.
The Critical Limitation: One Level Only
The wildcard pattern matches exactly one additional label, not an arbitrary depth of nesting. A certificate for *.example.com covers shop.example.com but does not cover api.shop.example.com — a second-level subdomain requires its own separate wildcard (*.shop.example.com) or an individually issued certificate for that specific nested subdomain. This is one of the most common points of confusion, since intuitively "wildcard" suggests unlimited coverage, when the actual technical specification is considerably narrower and more specific than that intuition suggests.
The Bare Domain Isn't Automatically Included Either
A second, equally common gap: a wildcard certificate for *.example.com does not, by itself, cover the bare root domain example.com without the "www" or any other subdomain prefix — the wildcard pattern specifically requires a label before the base domain, and a completely bare domain has no such label to match. Most certificate authorities address this by issuing wildcard certificates with the bare domain included as an additional Subject Alternative Name alongside the wildcard pattern, but this isn't universal or automatic across every issuer, and it's worth explicitly confirming a specific certificate includes bare-domain coverage rather than assuming it based on the wildcard designation alone.
Why Wildcard Certificates Require Extra Validation Care
Because a wildcard certificate implicitly grants coverage for any future subdomain matching the pattern, certificate authorities generally require a somewhat more rigorous domain validation process than a single-domain DV certificate — commonly requiring a DNS-based validation method specifically, rather than the simpler HTTP file-based validation sometimes available for single-domain issuance, since DNS control is considered a stronger overall proof of authority over the entire domain and everything beneath it, precisely because wildcard coverage is so broad in scope.
The Security Tradeoff of Broad Coverage
A wildcard certificate's private key, if ever compromised, exposes every current and future subdomain covered by that pattern simultaneously, rather than just a single specific subdomain the way a narrowly scoped individual certificate's compromise would. This concentrates risk in a single private key in a way some security-conscious organizations deliberately avoid, particularly for environments where different subdomains are managed by genuinely different teams or have meaningfully different security postures — a compromised key on a low-security marketing subdomain server, for instance, would also compromise the certificate covering a completely separate, more sensitive subdomain if both were issued under the same wildcard.
When SAN Certificates Are the Better Alternative
For organizations managing a known, finite list of specific subdomains rather than an open-ended, growing set, a SAN (Subject Alternative Name) certificate — covering an explicit, enumerated list of exact hostnames rather than a pattern — is often the more appropriate choice, discussed in more depth in the comparison piece elsewhere on this blog. SAN certificates avoid the single-point-of-compromise risk concentration of a wildcard while still consolidating multiple specific hostnames under one certificate, at the cost of needing to reissue the certificate whenever a new hostname needs to be added to the covered list.
Automation Makes the Multiple-Certificate Alternative More Viable
It's worth noting that the traditional case for wildcard certificates — avoiding the operational overhead of managing many individual certificates — has weakened somewhat as automated issuance and renewal (through Let's Encrypt's ACME protocol and similar tooling, discussed elsewhere on this blog) has become standard. When individual certificates can be issued and renewed with zero manual effort, the operational convenience argument for a single wildcard covering many subdomains becomes less decisive than it was in an earlier era when every certificate required manual purchase and installation.
Wildcard Validation Requires DNS Access, Which Isn't Always Trivial
A practical wrinkle worth planning for in advance: because wildcard issuance typically requires DNS-01 validation rather than the simpler HTTP-based method, obtaining a wildcard certificate means whatever system is requesting it needs programmatic access to create and remove DNS TXT records at your DNS provider — a requirement that's trivial with a modern DNS provider offering a well-documented API, but can become a genuine obstacle with a legacy or restrictive DNS host that doesn't support this kind of automated record management, sometimes forcing a DNS provider migration as an unplanned prerequisite simply to make wildcard automation possible in the first place.
The Takeaway
A wildcard certificate's actual coverage — exactly one subdomain level, with the bare root domain requiring separate, explicit inclusion — is narrower and more precise than the term casually suggests, and understanding this precisely prevents both unexpected coverage gaps and, for security-conscious deployments, an unnecessary concentration of risk in a single, broadly-scoped private key.
Tags: SSL configuration, subdomains, wildcard certificates