Cybersecurity glossary
What is a Wildcard Certificate?
Learn what a wildcard TLS certificate is, how *.example.com covers subdomains, security trade-offs versus SANs, and best practices for issuing and protecting wildcards.
Definition
A wildcard certificate is an X.509 TLS certificate whose subject alternative name uses a wildcard DNS label (typically *.example.com) so a single certificate can authenticate many hostnames under one parent domain.
Why teams use wildcard certificates
Microservices and ephemeral environments create endless hostnames. Issuing a unique certificate per host is ideal but operationally heavy. A wildcard certificate covers *.example.com with one key pair—convenient, and higher stakes if that key leaks.
What a wildcard covers
| Name pattern | Typically covered? |
|---|---|
| *.example.com | Yes — one label (api.example.com) |
| example.com | Only if explicitly included as a SAN |
| a.b.example.com | No — needs *.b.example.com or exact SAN |
| other.com | No |
Operational benefits and risks
Fewer renewals
One lifecycle to automate for many hosts.
Dynamic hostnames
Useful when subdomains are created frequently.
Larger blast radius
Stolen key impersonates every matching subdomain.
Key distribution pressure
Temptation to copy one private key to many servers.
Safer wildcard practices
Decide scope deliberately
Prefer exact SANs for high-value hosts; wildcards for low-risk dynamic sets.
Protect the private key
HSM/KMS where possible; minimize hosts that hold the key.
Automate issuance
Short lifetimes via ACME reduce exposure windows.
Monitor CT logs
Alert on unexpected wildcard issuance for your domains.
Plan revocation
Know how to revoke and replace quickly if compromise is suspected.
- Include the apex name explicitly if you need HTTPS on example.com.
- Avoid sharing one wildcard private key across unrelated trust zones.
- Prefer short-lived certificates and automated rotation.
- Segment: marketing wildcards should not cover payment hostnames if avoidable.
- Monitor Certificate Transparency for unexpected *.yourdomain issuance.
- Document which systems store wildcard private keys.
- Test multi-level subdomain needs; a single * is not recursive.
- Revoke promptly on suspected key exposure—do not wait for expiry.
The practical takeaway
A wildcard certificate authenticates many subdomains with one cert—and concentrates risk in one private key. Use wildcards when operations demand them, protect keys fiercely, and prefer narrower SANs for crown-jewel hosts.
Convenience is not free: every extra hostname the star covers is another hostname an attacker can impersonate if the key leaks.
Related security terms
Frequently asked questions
What is a wildcard certificate in simple terms?
One TLS certificate that works for many subdomains, like secure.example.com and api.example.com, using a name such as *.example.com.
Does *.example.com cover example.com itself?
Usually not. The bare apex often needs a separate name in the certificate (example.com plus *.example.com).
Does it cover multi-level subdomains?
A single * typically covers one label only—so *.example.com covers a.example.com but not a.b.example.com.
What are the risks of wildcards?
If the private key is stolen, attackers can impersonate any matching subdomain. Blast radius is larger than a single-host cert.
Wildcard vs many SAN names?
SANs list exact hosts and limit scope. Wildcards are convenient for dynamic hosts but expand key compromise impact.
Are wildcard certificates allowed everywhere?
Public CAs issue them under policy after domain control validation. Some internal PKIs restrict or ban wildcards.
References
Explore authoritative guidance and frameworks related to wildcard certificate.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.