Wildcard vs SAN Certificates: Which One Should You Choose
Learn the difference between wildcard and SAN SSL certificates, what hostnames they cover, and when each option makes sense.
Introduction
Choosing the right SSL certificate depends on which hostnames you need to secure. A wildcard certificate can cover many first-level subdomains under one domain, while a SAN certificate lists specific hostnames inside one certificate.
Both options can be correct. The best choice depends on how many subdomains you use, how often hostnames change, how much control you need, and whether you want broad coverage or precise coverage.
Quick answer
Use a wildcard certificate when you need to secure many first-level subdomains such as app.example.com, shop.example.com and blog.example.com. Use a SAN certificate when you need to secure specific hostnames, such as example.com, www.example.com and app.example.net, in one certificate.
Wildcard certificates
A wildcard certificate secures multiple first-level subdomains under the same domain.
*.example.comCan cover:
- app.example.com
- shop.example.com
- blog.example.com
Usually does not cover:
- example.com
- dev.app.example.com
- example.net
A wildcard certificate is useful when you create many subdomains under one domain.
SAN certificates
A SAN certificate, also called a multi-domain certificate, secures a specific list of hostnames. SAN means Subject Alternative Name.
example.com
www.example.com
app.example.com
example.net
www.example.netA SAN certificate is useful when you need exact control over several domains or subdomains in one certificate.
Wildcard vs SAN
Wildcard certificate
- Coverage: Many first-level subdomains under one domain.
- Example: *.example.com
- Best for: Many subdomains under the same domain.
- Strength: Flexible for new subdomains.
- Limitation: Usually does not cover root domain unless added separately.
SAN certificate
- Coverage: Specific hostnames listed in the certificate.
- Example: example.com, www.example.com, app.example.com
- Best for: Specific domains, subdomains or multiple domains.
- Strength: Precise control.
- Limitation: Needs reissue when adding new names.
Wildcard coverage
A wildcard certificate covers one label level.
app.example.com
mail.example.com
shop.example.comexample.com
dev.app.example.com
example.orgTo cover both example.com and *.example.com, the certificate must include both names.
example.com
*.example.comSAN coverage
A SAN certificate covers only the hostnames listed in the certificate’s SAN field.
example.com
www.example.com
app.example.com
api.example.comThis certificate covers those exact names, but not shop.example.com, blog.example.com or dev.api.example.com unless they are also listed.
SAN certificates are predictable because every covered hostname is explicitly listed.
Why this matters
This matters because choosing the wrong certificate type can cause hostname mismatch errors, unnecessary certificate reissues, or overly broad certificate coverage. A certificate should match the way your website, subdomains, apps, CDN and hosting environment are actually structured.
The decision is especially important for SaaS platforms, staging environments, multi-domain websites and hosting setups with many subdomains.
How to check coverage
Use SSL Checker to inspect which hostnames your current certificate covers.
When checking coverage, review
These six checks help confirm certificate hostname coverage.
Current hostname
Confirm the certificate covers the exact hostname visitors use.
SAN list
Check all hostnames included in the certificate.
Wildcard entry
Check whether the certificate includes a wildcard such as *.example.com.
Root domain coverage
Confirm whether example.com is included separately.
WWW coverage
Confirm whether www.example.com is included if used.
Subdomain depth
Check whether deeper subdomains need separate coverage.
Check certificate coverage
Use SSL Checker to review SAN names, wildcard coverage and hostname match.
Common problems
Wildcard does not cover root domain
High*.example.com may cover app.example.com but not example.com.
Next step: Issue a certificate that includes both example.com and *.example.com.
Wildcard does not cover deeper subdomains
Medium*.example.com does not normally cover dev.app.example.com.
Next step: Add a specific SAN name or use a certificate for the deeper subdomain.
SAN certificate missing a hostname
HighThe hostname visitors use is not listed in the certificate SAN field.
Next step: Reissue the certificate with the missing hostname included.
WWW version not included
MediumThe certificate covers example.com but not www.example.com, or the opposite.
Next step: Add both names or redirect consistently to the covered hostname.
Too many unrelated names in one SAN certificate
LowA single certificate contains many unrelated hostnames, making management harder.
Next step: Split certificates by project, environment or domain group if needed.
Wildcard used too broadly
MediumA wildcard certificate may expose broader risk if the private key is reused across many systems.
Next step: Limit where wildcard private keys are installed and rotate carefully.
Certificate reissued but old one still active
MediumThe new wildcard or SAN certificate exists, but the server or CDN still serves the old certificate.
Next step: Install the new certificate on the active server, CDN or proxy.
How to choose
-
Step 1: List all required hostnames
Include root domain, www, app subdomains, API subdomains, staging names and CDN hostnames.
-
Step 2: Group hostnames by domain
Decide whether most names belong under one domain or across multiple domains.
-
Step 3: Choose wildcard for many subdomains
Use wildcard when you need flexible first-level subdomain coverage under one domain.
-
Step 4: Choose SAN for specific names
Use SAN when you need precise hostnames, multiple domains or controlled certificate scope.
-
Step 5: Include root and www explicitly
Do not assume wildcard automatically covers the root domain.
-
Step 6: Install on the active endpoint
Update the certificate on hosting, CDN, reverse proxy or load balancer.
-
Step 7: Re-check coverage
Use SSL Checker to confirm the public certificate covers every required hostname.
Decision examples
Small business website
Needs example.com and www.example.com. Recommended: SAN certificate with both names.
SaaS app
Needs app.example.com, api.example.com and many customer subdomains. Recommended: Wildcard or mixed wildcard + SAN, depending on architecture.
Multi-brand company
Needs example.com, example.net and example.org. Recommended: SAN certificate or separate certificates.
Many staging subdomains
Needs dev.example.com, test.example.com and staging.example.com. Recommended: Wildcard may be simpler if all are first-level subdomains.
High-security environment
Needs strict separation between services. Recommended: Separate SAN certificates or smaller scoped certificates instead of one broad wildcard.
Certificate examples
*.example.com
Covers:
app.example.com
shop.example.com
mail.example.com
Does not usually cover:
example.com
dev.app.example.comexample.com
*.example.comexample.com
www.example.com
app.example.com
api.example.comopenssl s_client -connect app.example.com:443 -servername app.example.com
curl -I https://app.example.comThese examples are illustrative. Certificate coverage depends on the actual SAN names listed in the issued certificate.
Security tradeoffs
Wildcard certificates are convenient, but they can create broader operational risk if the same private key is installed on many servers. If one system is compromised, the wildcard certificate may need to be replaced everywhere.
SAN certificates offer more precise control, but they require updates when new hostnames are added.
Wildcard
More flexible, broader scope.
SAN
More controlled, less flexible.
Separate certificates
Most isolated, more management work.
There is no universal best choice. Choose based on infrastructure, security needs and maintenance capacity.
Frequently asked questions
Does *.example.com cover example.com?
Usually no. Add example.com separately if the root domain must be covered.
Does *.example.com cover dev.app.example.com?
Usually no. It covers one subdomain level, such as app.example.com, not deeper names.
What does SAN mean?
SAN means Subject Alternative Name. It is the certificate field listing the hostnames covered by the certificate.
Can a certificate be both wildcard and SAN?
Yes. A certificate can include wildcard names and specific SAN names.
Which is better, wildcard or SAN?
Wildcard is better for many first-level subdomains. SAN is better for specific hostnames or multiple domains.
Is a wildcard certificate less secure?
Not automatically, but it can create broader risk if the same private key is reused across many systems.
When should I use separate certificates?
Use separate certificates when services, teams, environments or security boundaries should stay isolated.
Related tools
Use these free tools to verify your configuration after applying changes.
Related guides
Browse all SSL & HTTPS guides →Need help applying this fix?
Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.
Was this guide helpful?
Your feedback helps us improve our guides for everyone.
Thanks for your feedback!