Wildcard Certificate

What is a wildcard certificate?

A wildcard certificate is a TLS/SSL certificate that secures a domain and all of its first-level subdomains with a single certificate, using the asterisk notation *.example.com. Instead of obtaining and managing a separate certificate for www.example.com, api.example.com, blog.example.com, shop.example.com, and so on, one wildcard cert covers them all. Its appeal is convenience and manageability: organizations with many subdomains avoid the operational overhead of issuing, deploying, and renewing dozens of individual certificates, and can spin up new subdomains without provisioning a new cert each time.

What it covers — and what it doesn’t

The scope of a wildcard is precise and a frequent source of confusion. *.example.com covers exactly one level of subdomain: it secures anything.example.com, but it does not cover the bare/apex domain example.com itself (you typically need to include that as an additional name — most wildcard certs are issued for both example.com and *.example.com), and it does not cover multi-level subdomains like a.b.example.com (that would need *.b.example.com, a separate wildcard). So a wildcard is broad in breadth (all subdomains at one level) but shallow in depth (only that one level). This distinguishes it from a SAN (Subject Alternative Name) / multi-domain certificate, which lists a specific set of explicit names (possibly across different domains) — SAN certs cover exactly the names you enumerate (more control, but you must know and list them), while wildcards cover any name at the level (more flexible for unknown/growing subdomains, less explicit). The choice between them: wildcard when you have many, changing subdomains under one domain; SAN when you have a known, bounded set of specific hostnames (possibly spanning domains).

The security tradeoff — convenience concentrates risk

The essential thing to understand about wildcards is that their convenience comes with concentrated risk, and this is where the real engineering judgment lies. Because one certificate and one private key secure all subdomains, that single private key becomes a high-value single point of failure: if the wildcard’s private key is compromised, the attacker can impersonate every subdomain — login.example.com, payments.example.com, all of them — with a valid certificate, a much larger blast radius than a compromised single-subdomain cert. This risk is amplified by how wildcards are often deployed: the same key/cert gets distributed across many servers and services (every subdomain’s host needs it), so the key exists in many places, each an opportunity for exposure — and a compromise anywhere exposes everything. This matters especially when subdomains have different trust/security levels: putting the same wildcard key on a hardened payments server and a less-secure marketing microsite means a breach of the weak site’s key compromises the payments subdomain too. The mitigations and considerations: protect the wildcard key rigorously and limit where it’s deployed; consider not using a wildcard for your most sensitive subdomains (give payments.example.com its own dedicated cert so its security is isolated from the wildcard’s broad exposure); be aware wildcards can’t be as tightly validated (they’re domain-validated broadly, and some high-assurance/EV scenarios don’t offer wildcards); and note the modern context — with free, automated certificates (Let’s Encrypt via ACME, including wildcard support via DNS validation), the old cost/effort argument for wildcards has weakened: automated per-subdomain certificates are now cheap and easy, so the convenience case for wildcards is smaller than it once was, and many teams prefer automated individual certs (better isolation, smaller blast radius) except where the sheer number or dynamism of subdomains makes a wildcard genuinely simpler. The recurring mistakes: using one wildcard key everywhere including sensitive subdomains (concentrating breach impact), spreading the wildcard key across many servers without recognizing each as an exposure point, and reaching for a wildcard by habit when automated per-subdomain certs would give better isolation.

What people get wrong

• Using one wildcard key for sensitive and insensitive subdomains alike — a compromise anywhere it’s deployed lets an attacker impersonate every subdomain, including payments/login; isolate high-value subdomains with dedicated certs.
• Misunderstanding the scope: *.example.com covers one subdomain level only — not the apex example.com, and not a.b.example.com; assuming broader coverage causes certificate errors.
• Reaching for wildcards by default — with free automated per-subdomain certs (ACME/Let’s Encrypt), individual certificates now give better breach isolation with little extra effort; use wildcards mainly for large or dynamic subdomain sets.

Primary source: Let’s Encrypt: Wildcard certificates