Wildcard SSL Certificates: When and How to Use Them
A wildcard SSL certificate secures a domain and all its single-level subdomains with a single certificate. Instead of buying separate certificates for www.example.com, api.example.com, and app.example.com, a wildcard cert for *.example.com covers them all.
How Wildcards Work
A wildcard certificate uses an asterisk (*) in the leftmost position of the domain name: *.example.com. This matches:
www.example.com✓api.example.com✓app.example.com✓mail.example.com✓anything.example.com✓
It does NOT match:
example.com✗ (the base domain itself — though most CAs include it as a SAN)sub.api.example.com✗ (multi-level subdomains)example.org✗ (different domain)
Wildcard vs Individual Certificates
| Aspect | Wildcard | Individual |
|---|---|---|
| Coverage | All subdomains (one level) | Specific domains only |
| Management | One cert to manage/renew | Multiple certs to track |
| Cost | One purchase | Per-domain cost |
| Security risk | Higher — key compromise affects all subdomains | Lower — isolated per domain |
| Revocation | Revoking affects all subdomains | Can revoke individually |
| Validation | DV or OV only (no EV wildcards) | DV, OV, or EV |
When to Use Wildcards
- Many subdomains: When you have 5+ subdomains and adding more frequently
- Dynamic subdomains: SaaS platforms where each customer gets a subdomain (tenant1.app.com)
- Development environments: dev.example.com, staging.example.com, test.example.com
- Simplified management: When you want to reduce certificate renewal complexity
When NOT to Use Wildcards
- Few subdomains: 2-3 subdomains don't justify the security trade-off
- Different servers: If subdomains run on different servers, each server needs the private key — expanding the attack surface
- EV needed: Extended Validation certificates cannot be wildcards
- Multi-level subdomains:
*.example.comwon't coversub.api.example.com
Security Considerations
- Key distribution: Every server using the wildcard needs the private key. More copies = more risk.
- Blast radius: If the private key is compromised, ALL subdomains are affected. An attacker could impersonate any subdomain.
- No EV: Certificate Authorities do not issue EV wildcards for security reasons.
- Subdomain takeover: If you stop using a subdomain but DNS still points to a decommissioned service, attackers may claim it — and your wildcard makes it look legitimate.
Let's Encrypt Wildcards
Let's Encrypt issues free wildcard certificates since 2018, but with a requirement:
- DNS-01 challenge required: You must prove domain ownership by creating a TXT DNS record. HTTP-01 challenges don't work for wildcards.
- Automation: Use certbot with a DNS plugin or acme.sh with your DNS provider's API документацию for automatic renewal.
# Certbot with Cloudflare DNS
certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d example.com -d *.example.comConfiguration Tips
- Include base domain: Request both
example.comand*.example.comin your certificate (as SANs). - Automate renewal: Wildcard certs expire too. Set up automatic renewal with DNS validation.
- Minimize key distribution: Use a reverse proxy/load balancer as the TLS termination point — only one server needs the private key.
- Monitor Certificate Transparency: Watch CT logs for unexpected certificates issued for your domain.
- Rotate on compromise: Have a plan to quickly revoke and reissue if the key is compromised.
Conclusion
Wildcard certificates are a powerful tool for managing SSL across many subdomains. They simplify management but increase security risk through wider key distribution. Use them when you have dynamic or numerous subdomains, but always minimize private key exposure by terminating TLS at a single point where possible.
Check your website right now
Check now →