Wildcard Certificate (Wildcard SSL certificate)

A wildcard certificate contains a name like *.example.com in its Subject Alternative Name extension. The asterisk may only be the entire leftmost label, and it matches exactly one label: www.example.com and api.example.com are covered, but example.com itself and a.b.example.com are not. Most wildcard certificates therefore list both *.example.com and example.com.

Why it matters

Wildcards are convenient when you run many subdomains or create them dynamically, for example one per customer in a SaaS product, because one certificate covers them all without reissuing. The trade-off is that the same private key is usually copied to every server that uses the certificate, so a compromise on one host exposes all subdomains. To get a wildcard from an ACME CA such as Let's Encrypt (supported since March 2018), you must use the DNS-01 challenge; HTTP-01 cannot prove control of every possible subdomain. EV certificates cannot contain wildcards at all.

Example

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

Certbot asks you to publish a TXT record at _acme-challenge.example.com; in production, use a DNS provider plugin so renewals run unattended.

Common misconceptions

• *.example.com also covers example.com. It does not; add the apex as a separate name.
• A wildcard covers deeper levels. *.example.com does not match a.b.example.com; you would need *.b.example.com.
• One wildcard is always simpler and safer. It is simpler to buy and deploy, but key sharing widens the blast radius; separate certificates or a multi-domain certificate per service limit the impact of a leak.