Both wildcard and SAN (Subject Alternative Name) certificates solve the same core problem — securing multiple domains or subdomains with one certificate. But they work differently and have different costs, limitations, and use cases. Picking the wrong type leads to either unnecessary expense or coverage gaps.
What Wildcard Certificates Cover
A wildcard certificate secures *.example.com — one asterisk replacing one level of subdomain. So a single wildcard cert covers:
www.example.comapi.example.commail.example.comshop.example.com- Any other direct subdomain of
example.com
What it does not cover:
example.comitself (the apex domain — though CAs now include it as an extra SAN on most wildcard certs)sub.api.example.com(two levels deep — the wildcard only covers one level)otherdomain.com
That second limitation catches people out. If you’re running staging.api.example.com, a wildcard for *.example.com doesn’t cover it. You’d need a wildcard for *.api.example.com or add the specific subdomain to a SAN cert.
How SAN Certificates Work
A SAN certificate explicitly lists every domain it covers. There’s no pattern matching — each domain is named individually in the certificate’s Subject Alternative Name field.
Subject Alternative Names:
example.com
www.example.com
api.example.com
anotherdomain.com
shop.different-brand.comYou can mix and match completely different domains. This is something a wildcard can never do — it’s always locked to one parent domain.
Commercial SAN certificates can cover 100 or more domains in a single certificate. This is useful for large organizations managing many distinct domains.
Let’s Encrypt: Both Are Free
For Let’s Encrypt certificates:
- Wildcard certs require DNS-01 challenge (you need API access to your DNS provider)
- SAN certs (up to 100 domains) use HTTP-01 challenge (simpler, just need a web server)
- There’s no cost difference — both are free
Practically, if you’re using Let’s Encrypt and have a compatible DNS provider (Cloudflare, Route53, etc.), getting a wildcard is straightforward with Certbot’s DNS plugins. If you’re on a DNS provider without automation support, managing a SAN list of specific subdomains via HTTP validation is easier. For complete setup instructions, check our Let’s Encrypt with Certbot guide.
Commercial Certificates: Price Gap Is Real
Paid certificate pricing varies significantly between types:
- Single domain: $10–$100/year
- Multi-domain SAN (5–10 domains): $80–$300/year
- Wildcard: $100–$700/year
- Wildcard + SAN for other domains: $300–$1000/year
These numbers vary a lot by CA and validation level. If you have 3 specific subdomains that will never change, a cheap SAN cert covering those three plus the apex domain is likely cheaper than a wildcard. If you’re actively creating new subdomains, a wildcard saves you from buying new certificates or reissuing constantly.
Validation Levels: DV, OV, and EV
Regardless of single/wildcard/SAN, certificates come in three validation levels:
DV (Domain Validation): The CA only verifies you control the domain. No identity verification. Fast, cheap, and what Let’s Encrypt issues. The browser padlock looks the same as OV to end users in most modern browsers.
OV (Organization Validation): The CA verifies your domain control plus your organization’s legal existence. Your company name appears in the certificate details. Visible if users check the cert, but most don’t.
EV (Extended Validation): The most thorough vetting — legal existence, physical address, telephone verification, the works. Used to show the company name in a green bar in browser address bars, but modern browsers (Chrome, Firefox) removed that visual distinction years ago. Now EV looks the same as DV to most users.
My take: EV is hard to justify for most use cases today. The visual differentiation that used to be its main selling point is gone. OV makes sense for financial services or healthcare where compliance requirements mention it. DV is appropriate for the vast majority of sites.
Wildcards can be DV or OV. EV wildcard certificates don’t exist by design — EV validation is per-specific-domain by the CA/Browser Forum rules.
Security Implications of Wildcard Certificates
Using a single private key for all subdomains is a single point of failure. If the private key for *.example.com is compromised, every subdomain is at risk. Compare that to individual certificates — a compromised key affects only that specific domain.
This matters more as organizations grow. If your development team has access to the wildcard cert for dev.example.com, they effectively have a valid certificate for payments.example.com too. Separating certificates provides better access control over sensitive subdomains.
Wildcards are also harder to revoke selectively. You can’t revoke the wildcard “just for api.example.com” — you revoke the whole thing and replace it, affecting every subdomain.
For internal tools, development environments, and non-sensitive subdomains, a wildcard is practical. For payment processing, authentication endpoints, or API services with sensitive data, individual certificates (or narrow SAN certs) are worth the extra management overhead.
Certificate Transparency and Subdomain Enumeration
Every publicly issued certificate gets logged to Certificate Transparency (CT) logs. Anyone can query these logs at crt.sh.
This means when you issue a wildcard cert, the wildcard pattern itself is logged (*.example.com). But when you issue specific SAN certs, the exact subdomain names are logged — staging.example.com, internal-api.example.com, admin.example.com.
CT logs are public. Issuing a SAN cert that explicitly names admin.example.com tells the world that subdomain exists. With a wildcard, you only reveal that subdomains exist, not their names.
For most use cases this doesn’t matter. But if you’re trying to keep internal service subdomain names from being easily discoverable, wildcards are slightly better than SAN certs with explicit internal names.
Managing Wildcard Certificate Renewal
Wildcard renewal requires DNS validation every time. If you’re using automated DNS validation (Certbot + Cloudflare plugin, for example), this is seamless. If you’re using manual DNS validation, you need to create a TXT record every 60–90 days — which is painful enough that most people eventually set up automation.
SAN certs renewed via HTTP validation are easier to automate because any server that serves HTTP on the covered domains can complete the validation.
Practical Decision Guide
Use a wildcard when:
- You have many subdomains (more than ~5)
- You regularly create new subdomains
- You want to reduce certificate management overhead
- You’re comfortable with DNS API automation for renewal
Use a multi-domain SAN cert when:
- You have a small, stable set of domains to cover
- You need to cover completely different domain names under one cert
- You can’t automate DNS validation
- You want to isolate sensitive subdomains from a shared private key
Use individual certs when:
- Security isolation between services matters
- You’re using Let’s Encrypt with simple HTTP validation
- You have a small number of domains that change rarely
- You want the ability to revoke or renew each service independently
Most modern infrastructure uses a mix of all three. Let’s Encrypt makes individual certs and SAN certs essentially free and automatically maintained. Commercial wildcards still make sense for large deployments where centralized certificate management reduces operational complexity.