Two approaches to multi-domain coverage
Both wildcard and SAN certificates solve the same basic problem: you have multiple hostnames that need TLS protection, and you do not want to manage one certificate per name.
But the two types work in fundamentally different ways, and the choice has consequences for security, flexibility, and operations.
What does a wildcard certificate cover?
A wildcard certificate covers all subdomains at one level under a specific domain. A certificate for *.example.com covers:
www.example.commail.example.comapi.example.comintranet.example.com- ... and all other subdomains at that level.
It does not cover:
example.com(the root domain itself, unless added as a SAN)sub.www.example.com(two levels deep)example.net(a different domain)
When ordering via the website, FairSSL automatically includes the root domain for free when you order a wildcard. On the DigiCert family, the names the wildcard covers are also free. With ACME you list all names yourself.
What does a SAN certificate cover?
A SAN certificate (Subject Alternative Name, also called Multi-Domain or UC certificate) covers an explicit list of names that you specify when ordering. The names can be from different domains:
www.example.comexample.comwww.example.netmail.othercompany.com
You decide which names to include. Most CAs allow 100-250 SAN names per certificate. Names can be added and removed upon reissuance.
Combine wildcard and SAN in the same certificate
It is possible to combine wildcard and SAN in the same certificate. Most Multi-Domain (SAN) certificates allow you to add wildcard names as SAN entries. This opens up several interesting possibilities:
- Wildcard plus specific hostnames: A certificate with
*.example.comas the primary name andapi.partner.com,shop.example.netas additional SAN names. You cover all subdomains under your main domain and specific names from other domains. - Multiple wildcards in one certificate: A certificate with
*.example.com,*.example.net, and*.staging.example.com. Each wildcard name counts as one SAN entry. - Wildcard plus root domain:
*.example.comdoes not coverexample.comitself (only subdomains). Add the root domain as a separate SAN for full coverage. When ordering from FairSSL via the website, this happens automatically and free.
A wildcard covers only one domain. *.example.com does not cover *.example.net or *.othercompany.com. If you need coverage across different domains, each domain must be added as a separate SAN (either as a wildcard or a specific hostname).
Combination certificates are often the most flexible solution for businesses with multiple domains and many subdomains. The price is typically based on the number of SAN entries, where each wildcard name counts as one entry.
Security considerations
Wildcard certificates have a fundamental security challenge: the private key must be installed on all servers that use the certificate.
If you have *.example.com installed on your web server, mail server, API gateway, and development server, all four systems share the same private key. If one server is compromised, the attacker can use the key to impersonate all subdomains.
Blast radius
NSA recommends: Separate security zones
Do not use the same wildcard certificate on internet-facing servers and internal administration panels. If the public server is compromised, the attacker can use the stolen key for man-in-the-middle attacks against internal systems.
NSA (via NSA Cybersecurity Information Sheet, "Avoid Dangers of Wildcard TLS Certificates") specifically warns against using wildcard certificates on systems with different security levels. Their recommendation: do not use the same wildcard certificate on an internet-facing web server and an internal administration panel.
If your public web server is compromised and shares a certificate with your internal admin panel, the attacker can use the stolen key to set up a convincing man-in-the-middle against the admin panel. Separation is therefore the logical defence.
With SAN certificates, you can limit the blast radius by grouping names by security level. Customer-facing systems get one certificate, internal systems another.
Key reuse
Wildcard certificates invite key reuse. The same certificate (and therefore the same key) is installed on many servers. This conflicts with the principle of key isolation: ideally, each server should have its own private key, so that compromise of one server does not affect others.
With SAN certificates, you have the same problem, but on a smaller scale. You can limit the number of SAN names per certificate to keep the blast radius down.
Price comparison
Wildcard certificates are typically more expensive than a single-domain certificate, but cheaper than many individual certificates. The price is fixed regardless of how many subdomains you use.
SAN certificates are typically priced with a base fee plus a fee per additional SAN name. The first 1-5 SAN names are often included in the base price.
The price comparison depends on your scenario:
- Many subdomains under one domain: Wildcard is cheapest.
- 3-5 names from different domains: SAN certificate is cheapest.
- Mix of both: Some CAs offer SAN certificates with wildcard SANs (e.g.
*.example.comas a SAN name). This provides flexibility, but at a higher price.
See our product overview for current prices, or use the certificate selector to find the right type.
Combine the types
There is nothing wrong with using wildcard for development and staging, while production uses specific SAN certificates with tighter key control.
Automation and certificate lifetime
With SSL lifetimes heading towards 47 days (by 2029), automation of certificate issuance and installation becomes critical. Here, the two types have different characteristics:
Wildcard + ACME: Requires DNS-01 validation (you cannot use HTTP-01 for wildcards). Your ACME client must have access to create DNS TXT records. With FairSSL AutoDNS, it is a one-time setup with a CNAME redirect.
SAN + ACME: Can use either HTTP-01 or DNS-01 for each SAN name. HTTP-01 is simpler (no DNS access needed), but requires that all SAN names point to the server running the ACME client.
Best practices
- Avoid wildcard across security zones. Do not use the same wildcard certificate on public and internal systems. Issue separate certificates.
- Consider the blast radius. Group names in certificates by how critical they are. Customer-facing services in one certificate, internal ones in another.
- Automate. With 200-day certificates (and soon 100 and 47 days), manual processes are not sustainable. Use ACME regardless of certificate type.
- Use wildcard with care. A wildcard certificate is convenient, but it also covers subdomains you never thought about. If an attacker creates
phishing.example.comvia a DNS vulnerability, they already have a valid certificate. - Combine the types. There is nothing wrong with using a wildcard for development and staging, while production uses specific SAN certificates with tighter control.
Summary
| Property | Wildcard | SAN (Multi-Domain) |
|---|---|---|
| Coverage | All subdomains at one level | Explicit list of names |
| Cross-domain | No (only subdomains under one domain) | Yes (arbitrary domains and hostnames) |
| Combination | Can be combined: wildcard + SAN names + multiple wildcards in one certificate | |
| Blast radius | High (all subdomains) | Limited (only listed names) |
| ACME validation | DNS-01 required | HTTP-01 or DNS-01 |
| Price with many names | Fixed price | Increases with number of SANs |
| Validation | DV or OV | DV, OV, or EV |
| EV available | No | Yes |