A wildcard certificate for *.example.com is valid for any single name
directly under example.com. It's convenient: one certificate for
www, mail, vpn and any subdomain you add later. It also comes with
limits people regularly trip over, and a security trade-off.
What *.example.com covers
The wildcard matches exactly one label, and must be the whole leftmost label:
| Name | Covered by *.example.com? |
|---|---|
www.example.com |
Yes |
vpn.example.com |
Yes |
example.com |
No |
dev.app.example.com |
No |
To cover the bare domain, the certificate needs both names:
example.com and *.example.com (most CAs and ACME clients add both
when asked). For *.app.example.com, you need a second wildcard.
Extended Validation (EV) certificates can't be wildcards at all.
Getting one free
Let's Encrypt issues wildcards, but only with the DNS-01 challenge:
you prove control by creating a TXT record at _acme-challenge.example.com.
The usual HTTP check can't be used for wildcards.
To renew automatically, the ACME client needs API access to your DNS provider (certbot DNS plugins, acme.sh, Caddy, cert-manager and others support the common ones). With lifetimes shrinking to 200 days now, 100 days from March 2027 and 47 days from March 2029, a wildcard renewed by hand is a recurring outage waiting to happen: see 47-day SSL certificates.
The trade-offs
One key, many servers. A wildcard installed on the website, the firewall, the mail server and a contractor's staging box shares one private key across all of them. If any one of them is compromised, the attacker can impersonate every subdomain, and you have to replace the certificate everywhere at once.
Every copy must be renewed. The same certificate on five devices is five installs per renewal. Miss one and it expires on its own schedule: the classic renewed but not installed outage.
Hidden hostnames. CT logs record *.example.com, not the hosts that
use it. That keeps internal names out of public logs, but it also means a
CT search won't tell you where the certificate is installed. Keep your own
list.
When a wildcard makes sense
- Many short-lived or customer-specific subdomains on one platform
(
customer1.app.example.com), served by a load balancer or CDN that renews automatically. - A CDN or hosting platform that manages the wildcard for you.
When to use separate certificates
- Appliances: firewalls, VPNs, RD Gateway, mail servers. Give each its own certificate and key.
- Anything that a third party runs or that you'd revoke on its own.
- When automation is available per host anyway: with ACME, a certificate per name costs nothing extra.
Check your domain
The certificate finder lists every certificate in CT logs for your domain, wildcards included, and the SSL expiry checker shows what each host is actually serving and when it expires.