Wildcard vs. SAN Certificates: Which Is Right for You?
When you need to secure more than just a single domain, standard SSL certificates won't cut it. You'll need either a Wildcard certificate or a Multi-Domain (SAN) certificate. Both allow you to secure multiple hostnames with a single certificate, but they do so in different ways and are suited for different scenarios. Choosing the right one can simplify management and save costs.
What is a Wildcard Certificate?
A Wildcard SSL certificate is designed to secure a single domain and an unlimited number of its first-level subdomains. It uses an asterisk (*) in the Common Name (CN) field to represent any possible subdomain: CN = *.yourdomain.com.
A single Wildcard certificate for *.yourdomain.com will secure:
Note — it typically does not secure the bare domain (yourdomain.com) by default, though most CAs automatically add it as a SAN. It also does not secure second-level subdomains (e.g., test.api.yourdomain.com).
What is a Multi-Domain (SAN) Certificate?
A Multi-Domain certificate, also known as a Subject Alternative Name (SAN) or Unified Communications Certificate (UCC), allows you to secure multiple, completely different domain names with a single certificate. The primary domain is listed in the Common Name (CN), and all additional domains are listed in the Subject Alternative Name (SAN) extension: SANs: [domain1.com, domain2.net, sub.domain1.com].
A single SAN certificate can secure a mix of names:
Note — you can even include Wildcards as one of the SANs (e.g., *.yourdomain.com), creating a powerful Multi-Domain Wildcard certificate.
Comparison: Wildcard vs. SAN
| Feature | Wildcard Certificate | SAN Certificate |
|---|---|---|
| Primary Use Case | Securing unlimited subdomains of a single domain. | Securing multiple different domain names. |
| Flexibility | Low. Limited to one domain and its direct subdomains. | High. Can mix and match any domain, subdomain, and IP address. |
| Scalability | Excellent for future subdomains. Add a new subdomain and it's automatically secured. | Requires reissuance. Adding a new domain means reissuing the certificate with the new name added to the SAN list. |
| Cost | Often cheaper if you have many subdomains on a single domain. | Priced per SAN slot. Can be more cost-effective than buying individual certificates for different domains. |
| Validation Levels | Available as Domain Validated (DV) and Organization Validated (OV). Not available as Extended Validation (EV). | Available for all validation levels: DV, OV, and EV. |
| Example | Secures api.certnotify.com, blog.certnotify.com, etc. | Secures certnotify.com, certnotify.org, and mysite.co.uk. |
When to Choose Which Certificate
- You need to secure multiple subdomains for a single base domain.
- You plan to add more subdomains in the future and want them to be secured automatically without reissuing the certificate.
- Your security policy allows for a single private key to be shared across multiple servers (e.g., api., www., app.).
- You only need DV or OV level validation.
- You need to secure several completely different domain names.
- You need to secure a mix of base domains and subdomains.
- You need an EV (Extended Validation) certificate for multiple domains.
- You are securing a Microsoft Exchange or Office Communications Server environment, which often requires specific hostnames.
- You want to explicitly list every hostname for tighter security control.
Use our free Certificate Chain Checker to inspect any certificate's Subject Alternative Names — seeing exactly which domains and subdomains are covered.
Common questions
What is the difference between a wildcard and a SAN SSL certificate?
A wildcard certificate (*.example.com) covers one domain pattern — all immediate subdomains of a single domain. A SAN (Subject Alternative Names) certificate explicitly lists multiple distinct domains (example.com, example.org, app.net) in one certificate. SANs are more flexible for multiple domains; wildcards are simpler for many subdomains of one domain.
Can a wildcard certificate cover nested subdomains?
No. *.example.com covers www.example.com and api.example.com but NOT sub.api.example.com. Nested subdomains require either a separate wildcard certificate (*.api.example.com) or a SAN certificate that explicitly includes the nested subdomain. Let's Encrypt supports both and issues them free of charge.
Are wildcard certificates a security risk?
They carry a higher risk than single-domain certificates because one private key protects all subdomains — if the key is compromised, all subdomains are at risk. Store the private key securely, limit server access, and consider using separate certificates for high-security subdomains like admin or payment. Let's Encrypt's 90-day wildcards reduce exposure windows compared to 1-year certificates.
When should I use a SAN certificate instead of a wildcard?
Use a SAN when: you need to cover multiple unrelated domains, you need nested subdomains (sub.api.example.com), you want to minimize blast radius from a key compromise, or you want explicit control over exactly which domains are included. Use a wildcard when you have many subdomains of one domain and want simplified management with one renewal.
References and further reading
The specifications and primary documentation this article is based on.
- RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- CA/Browser Forum
Publishes the Baseline Requirements every public CA must follow.
Read next
More guides on the same subject.