Choosing between wildcard and SAN (Subject Alternative Name) certificates is one of the most common decisions in SSL/TLS certificate management. This guide compares both certificate types, explains their security implications, and helps you choose the right approach for your infrastructure.
Quick Comparison
┌─────────────────────────────────────────────────────────────────────────────┐
│ Wildcard vs SAN Certificate Comparison │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ WILDCARD CERTIFICATE SAN CERTIFICATE │
│ *.example.com example.com │
│ ───────────────────── example.org │
│ www.example.com │
│ ✓ www.example.com api.example.com │
│ ✓ api.example.com shop.other-brand.com │
│ ✓ mail.example.com ───────────────────── │
│ ✓ anything.example.com │
│ ✓ future-subdomain.example.com ✓ Only listed domains │
│ ✗ No unlisted domains │
│ ✗ example.com (bare domain) ✗ No pattern matching │
│ ✗ sub.sub.example.com │
│ │
│ SECURITY SECURITY │
│ ───────── ───────── │
│ Higher risk if compromised Lower risk if compromised │
│ (any subdomain vulnerable) (only listed domains vulnerable) │
│ │
│ FLEXIBILITY FLEXIBILITY │
│ ──────────── ──────────── │
│ No certificate updates for Must update certificate for │
│ new subdomains new domains │
│ │
│ COST (Commercial) COST (Commercial) │
│ ────────────────── ────────────────── │
│ $75-200/year (unlimited) $10-30 per domain │
│ Best for 5+ subdomains Best for mixed domains │
│ │
│ Let's Encrypt: FREE Let's Encrypt: FREE │
│ (DNS-01 challenge required) (HTTP-01 or DNS-01) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Understanding Wildcard Certificates
A wildcard certificate uses an asterisk (*) to match any single label in a domain name.
What Wildcards Cover
Certificate: *.example.com
┌─────────────────────────────────────────────────────────────────────────────┐
│ Wildcard Coverage │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ✓ COVERED ✗ NOT COVERED │
│ ───────── ───────────── │
│ │
│ www.example.com example.com (bare domain) │
│ api.example.com dev.api.example.com (2 levels) │
│ mail.example.com sub.sub.example.com (2 levels) │
│ cdn.example.com other-domain.com │
│ dev.example.com example.org │
│ staging.example.com │
│ anything-new.example.com │
│ 123.example.com │
│ a.example.com │
│ │
│ Pattern: *.example.com matches [anything].example.com │
│ where [anything] is a single label (no dots) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Including the Bare Domain
Wildcard certificates don't cover the bare domain (example.com). Always request both:
# Certbot with Let's Encrypt
certbot certonly --dns-cloudflare \
-d "*.example.com" \
-d "example.com"
# CSR with OpenSSL (subjectAltName)
[alt_names]
DNS.1 = *.example.com
DNS.2 = example.com
Wildcard Use Cases
Good for Wildcards:
- Dynamic subdomains (user1.app.com, user2.app.com)
- Microservices with many endpoints (api., auth., db.*)
- Development/staging environments (dev., staging., test.*)
- Content delivery (cdn1., cdn2., static.*)
- Multi-tenant SaaS platforms
Avoid Wildcards When:
- You have only 2-3 subdomains (SAN is simpler)
- Security is critical (limits blast radius)
- Domains span different base domains
- You need fine-grained certificate control
Understanding SAN Certificates
SAN (Subject Alternative Name) certificates list each covered domain explicitly.
What SANs Cover
Certificate SANs:
- example.com
- www.example.com
- example.org
- api.example.com
- shop.other-brand.com
┌─────────────────────────────────────────────────────────────────────────────┐
│ SAN Coverage │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ✓ COVERED (explicitly listed) ✗ NOT COVERED │
│ ────────────────────────────── ───────────── │
│ │
│ example.com mail.example.com (not listed) │
│ www.example.com staging.example.com (not listed) │
│ example.org anything-else.example.com │
│ api.example.com │
│ shop.other-brand.com │
│ │
│ Only explicitly listed domains are covered. │
│ Adding new domains requires new certificate. │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
SAN Certificate Limits
| Certificate Authority | Max SANs | Notes |
|---|---|---|
| Let's Encrypt | 100 | Free |
| DigiCert | 250 | Enterprise pricing |
| Sectigo | 250 | Volume discounts |
| GlobalSign | 100 | Standard; more on request |
| GoDaddy | 100 | Per-SAN pricing |
SAN Use Cases
Good for SANs:
- Multiple distinct brands (brand1.com, brand2.com, brand3.com)
- Known, fixed set of domains
- High-security environments (explicit allow-list)
- Mixed apex domains and subdomains
- Consolidating certificates across acquisitions
Avoid SANs When:
- You frequently add new subdomains
- You have dynamic/user-generated subdomains
- You have 10+ subdomains of one base domain
Security Comparison
Blast Radius Analysis
┌─────────────────────────────────────────────────────────────────────────────┐
│ Security: Blast Radius Comparison │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ SCENARIO: Private key is compromised │
│ │
│ WILDCARD (*.example.com) SAN (listed domains only) │
│ ───────────────────────── ────────────────────────── │
│ │
│ Attacker can impersonate: Attacker can impersonate: │
│ │
│ ✗ www.example.com ✗ www.example.com │
│ ✗ api.example.com ✗ api.example.com │
│ ✗ mail.example.com ✗ example.com │
│ ✗ admin.example.com │
│ ✗ secure.example.com ✓ admin.example.com (NOT listed) │
│ ✗ bank.example.com ✓ bank.example.com (NOT listed) │
│ ✗ ANY-SUBDOMAIN.example.com ✓ future domains (NOT listed) │
│ ✗ future-domains.example.com │
│ ✗ phishing.example.com │
│ │
│ IMPACT: SEVERE IMPACT: LIMITED │
│ All subdomains compromised Only 3 listed domains compromised │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Recommendation by Security Level
| Security Level | Recommendation |
|---|---|
| High Security (Banking, Healthcare) | SAN certificates with minimum domains, or individual certs per service |
| Standard Security (Business apps) | SAN for production, Wildcard for dev/staging |
| Convenience-focused (Internal tools) | Wildcard for simplicity |
Combining Wildcards and SANs
You can include both wildcards and specific SANs in one certificate:
Certificate SANs:
- *.example.com (wildcard)
- example.com (bare domain)
- *.staging.example.com (second-level wildcard)
- partner-brand.com (different domain)
Multi-Domain Wildcard Example
# Request multi-domain wildcard from Let's Encrypt
certbot certonly --dns-cloudflare \
-d "*.example.com" \
-d "example.com" \
-d "*.example.org" \
-d "example.org" \
-d "*.other-brand.com" \
-d "other-brand.com"
This creates one certificate covering:
- All subdomains of example.com
- All subdomains of example.org
- All subdomains of other-brand.com
- The bare domains of all three
Cost Analysis
Let's Encrypt (Free)
Both wildcard and SAN certificates are free. Cost is only operational:
| Type | Cost | Requirement |
|---|---|---|
| Single Domain | Free | HTTP-01 or DNS-01 |
| SAN (up to 100) | Free | HTTP-01 or DNS-01 |
| Wildcard | Free | DNS-01 only |
| Multi-Wildcard | Free | DNS-01 only |
Commercial Certificates (Approximate)
| Scenario | Wildcard Cost | SAN Cost | Recommendation |
|---|---|---|---|
| 3 subdomains | $150/year | $90/year (3×$30) | SAN |
| 5 subdomains | $150/year | $150/year (5×$30) | Either |
| 10 subdomains | $150/year | $300/year | Wildcard |
| 20 subdomains | $150/year | $600/year | Wildcard |
| 3 different domains | N/A | $90/year | SAN |
Decision Framework
┌─────────────────────────────────────────────────────────────────────────────┐
│ Certificate Type Decision Tree │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ START: How many domains/subdomains? │
│ │ │
│ ┌──────────┴──────────┐ │
│ ▼ ▼ │
│ 1-3 domains 4+ subdomains │
│ │ │ │
│ ▼ ▼ │
│ ┌───────────────┐ Same base domain? │
│ │ SAN Certificate│ │ │
│ │ (simpler) │ ┌───────┴───────┐ │
│ └───────────────┘ ▼ ▼ │
│ YES NO │
│ │ │ │
│ ▼ ▼ │
│ Dynamic subdomains? ┌───────────────┐ │
│ │ │ SAN Certificate│ │
│ ┌───────┴───────┐ │ (multi-domain) │ │
│ ▼ ▼ └───────────────┘ │
│ YES NO │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────┐ High security? │
│ │ WILDCARD │ │ │
│ │ *.example.com │ ┌───┴───┐ │
│ └─────────────────┘ ▼ ▼ │
│ YES NO │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────┐ ┌─────────────────┐ │
│ │ SAN (explicit│ │ WILDCARD │ │
│ │ domains only)│ │ (convenience) │ │
│ └──────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Implementation Examples
Wildcard with Let's Encrypt
# Install Certbot with Cloudflare DNS plugin
sudo apt install certbot python3-certbot-dns-cloudflare
# Create credentials file
cat > ~/.secrets/cloudflare.ini << 'EOF'
dns_cloudflare_api_token = YOUR_API_TOKEN
EOF
chmod 600 ~/.secrets/cloudflare.ini
# Request wildcard certificate
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
-d "*.example.com" \
-d "example.com"
# Certificate location
# /etc/letsencrypt/live/example.com/fullchain.pem
# /etc/letsencrypt/live/example.com/privkey.pem
SAN with Let's Encrypt
# SAN certificate with HTTP-01 (no DNS plugin needed)
sudo certbot certonly \
--nginx \
-d "example.com" \
-d "www.example.com" \
-d "api.example.com" \
-d "shop.example.com"
# Or with standalone mode
sudo certbot certonly \
--standalone \
-d "example.com" \
-d "www.example.com" \
-d "api.example.com"
Kubernetes cert-manager
# Wildcard certificate
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: wildcard-example-com
spec:
secretName: wildcard-example-com-tls
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- "*.example.com"
- "example.com"
---
# SAN certificate
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: multi-domain
spec:
secretName: multi-domain-tls
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- "example.com"
- "www.example.com"
- "api.example.com"
- "example.org"
Conclusion
Choose Wildcard When:
- You have many subdomains of one base domain
- Subdomains are created dynamically
- Convenience outweighs security concerns
- You're managing development/staging environments
Choose SAN When:
- You need multiple different base domains
- Security is paramount (explicit allow-list)
- You have a small, fixed set of domains
- You want fine-grained control
Best Practices:
- Always include bare domain with wildcards (example.com + *.example.com)
- Use SAN for production, wildcard for non-production when security matters
- Monitor Certificate Transparency logs for unauthorized certificates
- Automate renewal regardless of certificate type
- Consider mTLS with individual certificates for service-to-service authentication
For complete certificate management guidance, see our TLS Certificate Complete Guide.