# developer tools# website monitoring
Wildcard vs SAN vs Single-Domain SSL Certificates: Which Do You Need?
SSL certificate types differ in how many domains and subdomains they cover. Choosing the wrong type either leaves some of your services unprotected or costs more than necessary. Here's the breakdown.
Single-Domain Certificates
A single-domain certificate covers exactly one fully-qualified domain name. It will cover yourdomain.com and usually www.yourdomain.com (most CAs include the www variant automatically as a SAN).
What it covers:
yourdomain.comwww.yourdomain.com(typically included)
What it doesn't cover:
api.yourdomain.comapp.yourdomain.com- Any other subdomain
Best for: Simple sites with a single domain and no subdomains that need HTTPS. Also appropriate when you're using Let's Encrypt per-service, where certificates are free and auto-renewed anyway.
Cost: Let's Encrypt — free. Commercial CAs — lowest cost tier.
Wildcard Certificates
A wildcard certificate covers a domain and all of its immediate subdomains using the * notation:
*.yourdomain.com
What it covers:
www.yourdomain.comapi.yourdomain.comapp.yourdomain.commail.yourdomain.com- Any other single-level subdomain
What it doesn't cover:
yourdomain.comitself (the apex domain) — you need this listed separately or use a SANdev.api.yourdomain.com— wildcards only cover one level deep- Completely different domains (
anotherdomain.com)
# Check if a wildcard covers a specific host
openssl x509 -in wildcard.crt -noout -text | grep -A2 "Subject Alternative"
# Should show: DNS:*.yourdomain.com, DNS:yourdomain.com
The apex domain caveat: *.yourdomain.com does not match yourdomain.com. You need the apex explicitly included. Most CAs include it as a SAN automatically — verify when ordering.
DNS validation for wildcards: Let's Encrypt requires DNS-01 challenge validation for wildcard certificates (HTTP-01 validation doesn't work for wildcards). This means you need either a DNS provider with an API that Certbot can use, or manual DNS validation. See how to rotate SSL certificates without breaking your site for the renewal workflow.
Best for: Services with multiple subdomains under one domain — SaaS apps with app., api., admin., docs., etc.
Cost: Let's Encrypt — free (with DNS-01 validation). Commercial CAs — mid-tier, typically $70–300/year.
SAN (Subject Alternative Name) / Multi-Domain Certificates
A SAN certificate lists multiple specific domains and subdomains explicitly. It can cover domains from completely different base domains.
yourdomain.com
www.yourdomain.com
api.yourdomain.com
anotherdomain.com
www.anotherdomain.com
What it covers:
- Any domain explicitly listed in the SAN field
- No wildcard coverage — each domain must be listed individually
What it doesn't cover:
- Any domain not in the SAN list
- Subdomains added after issuance (new subdomains require a new certificate)
# See all SANs in a certificate
openssl x509 -in certificate.crt -noout -text \
| grep -A1 "Subject Alternative Name"
Best for:
- Agencies managing certificates for multiple client domains on a single server
- Services that span multiple distinct domains
- When you need deep subdomain coverage (
dev.api.yourdomain.com) that wildcards can't handle
Cost: Let's Encrypt — free (up to 100 SANs per certificate). Commercial CAs — priced per SAN or in tiers.
Comparison Table
| Type | Covers | Doesn't cover | Let's Encrypt |
|---|---|---|---|
| Single-domain | One domain + www | Any other subdomain | Free |
| Wildcard | *.domain.com + apex | Multi-level subdomains, other domains | Free (DNS-01 only) |
| SAN / Multi-domain | Any listed domain | Unlisted domains, future subdomains | Free (up to 100 SANs) |
Wildcard vs SAN: Which to Choose?
Choose wildcard if:
- You have many subdomains under one domain
- Subdomains are created dynamically (new ones automatically covered)
- You're comfortable with DNS-01 validation for Let's Encrypt
Choose SAN if:
- You need to cover multiple completely separate domains
- You need deep subdomains (second-level:
staging.api.yourdomain.com) - You want simpler validation (HTTP-01 works for non-wildcard SANs)
Common pitfall: buying a wildcard when you actually need a SAN. For example: *.yourdomain.com does not cover staging.api.yourdomain.com. To cover that, you either need *.api.yourdomain.com (a second wildcard for that subdomain level) or a SAN listing it explicitly.
Certificate Monitoring Considerations
The type of certificate affects how you monitor it:
- Single-domain: monitor the one domain
- Wildcard: monitor the apex and your key subdomains — a wildcard being compromised affects all subdomains
- SAN: monitor each significant domain in the SAN list
Domain Monitor monitors SSL certificate expiry for each domain you add — when your wildcard or SAN certificate is approaching expiry, you get advance warning before any service is affected. Create a free account.
Also in This Series
More posts
Wildcard vs SAN vs Single-Domain SSL Certificates: Which Do You Need?
Wildcard, SAN (multi-domain), and single-domain SSL certificates cover different use cases. Here's a clear comparison to help you pick the right type — and avoid paying for coverage you don't need.
Read moreWhy DNS Works in One Location but Fails in Another
DNS resolves correctly from your office but fails for users in other countries or on different ISPs. Here's why geographic DNS inconsistency happens and how to diagnose which layer is causing it.
Read moreRegistrar Lock vs Transfer Lock: What's the Difference?
Registrar lock and transfer lock are often confused — and disabling the wrong one leaves your domain vulnerable. Here's a clear breakdown of what each does and when to use them.
Read moreSubscribe to our PRO plan.
Looking to monitor your website and domains? Join our platform and start today.