Wildcard vs SAN Certificate: Which to Choose in 2026

Wildcard and SAN (Subject Alternative Name) are two ways to cover multiple domains with a single SSL certificate. The choice affects cost, security, and automation. In this guide we compare the two, explain when each fits, and why for most modern projects a Let's Encrypt SAN cert beats a paid wildcard.

What a wildcard certificate is

A wildcard is a cert with *.example.com in the Common Name or SAN field. It covers every first-level subdomain — www.example.com, api.example.com, mail.example.com, etc. But it does NOT cover:

• The apex domain example.com itself (needs a separate SAN).
• Second-level subdomains — a.b.example.com is not covered by *.example.com.
• Other domains — example.org, example.net.

A proper wildcard config usually contains two names: example.com + *.example.com. Check your cert's SAN list via the enterno.io SSL Checker.

What a SAN certificate is

SAN (Subject Alternative Name) is an X.509 extension that lists many specific domains in one cert:

Subject Alternative Name:
    DNS:example.com
    DNS:www.example.com
    DNS:api.example.com
    DNS:admin.example.com
    DNS:example.org
    DNS:example.net

Every modern cert is technically a SAN cert — CN-only stopped being supported by Chrome 58 and later. Even a single-domain cert uses the SAN field. “SAN certificate” usually means a multi-domain cert with 2+ SANs.

Comparison: key differences

Parameter	Wildcard	SAN (multi-domain)
Syntax	*.example.com	explicit domain list
New subdomains	work automatically	require reissue
Different domains	no	yes
Nested subdomains	no (one level only)	each listed explicitly
Price (paid CA)	$150–400/year	$100–300/year for ~5 domains
Let's Encrypt	DNS-01 only	HTTP-01 or DNS-01
Compromise blast radius	larger (all subdomains)	localized
Automation	needs DNS API документацию access	easier with HTTP validation

When to choose wildcard

• Many subdomains created/removed dynamically (multi-tenant SaaS: acme.example.com, globex.example.com).
• You have a DNS provider with an API (Cloudflare, Route 53, DigitalOcean) — required for automated DNS validation.
• One key for all services of a domain — simpler for CDN integrations.
• You can't predict the subdomain list in advance.

When to choose SAN

• Small, fixed domain list (up to 100 per cert).
• Multiple TLDs (example.com + example.co.uk).
• Security — minimize compromise blast radius.
• Simpler automation — HTTP-01 needs no DNS access.
• Let's Encrypt is free — skip paid wildcards.

Automation: certbot + Let's Encrypt

SAN via HTTP-01 (easiest case):

sudo certbot certonly --webroot -w /var/www/html \
    -d example.com -d www.example.com \
    -d api.example.com -d admin.example.com

Wildcard via DNS-01 (Cloudflare):

# /etc/letsencrypt/cloudflare.ini
dns_cloudflare_api_token = YOUR_TOKEN

# Run
sudo certbot certonly \
    --dns-cloudflare \
    --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
    -d "*.example.com" -d example.com

Auto-renewal is the same for both — certbot renew reuses saved options. See Let's Encrypt: certbot setup.

Security: why wildcard is riskier

Key risk: one private key protects every subdomain. If the key leaks (backdoor on a server, insecure CI/CD, developer's laptop), an attacker can impersonate any subdomain, including bank.example.com or oauth.example.com. With SAN the blast radius is limited to the listed domains.

Wildcard best practices:

• Store the key in HSM or Secrets Manager, not on web-server disks.
• Use separate wildcards for prod/staging/dev.
• Rotate every 60–90 days (Let's Encrypt naturally does).
• Monitor new subdomains and certs via Certificate Transparency.

Hybrid approach

Large projects often combine: a wildcard for general subdomains (*.example.com) plus dedicated SAN certs for critical services (oauth, admin, payments). Compromising the wildcard doesn't affect critical paths, which have their own, more strictly guarded keys.

Frequently asked questions

Does a wildcard cover the apex domain?

No. *.example.com does not cover example.com itself — add it explicitly in SAN.

How many SANs can one cert have?

X.509 sets no limit, but CAs cap at 100–250. Let's Encrypt caps at 100. Need more — split into multiple certs or use wildcard.

Does wildcard work for a.b.example.com?

No. *.example.com covers one level only. For *.a.example.com you need a second wildcard.

What should I use for Kubernetes microservices?

Usually wildcard + cert-manager. Let's Encrypt DNS-01 automated via cert-manager is the de facto standard. SAN works if microservices are stable and few.

Conclusion

For 90% of projects, a Let's Encrypt SAN cert wins: free, safer, HTTP-01 automation. Wildcard only makes sense when subdomains are dynamic and their count is unknown. Check your current cert via the enterno.io SSL Checker to confirm SAN coverage, and let Monitors watch expiry for all variants.

X.509 SAN — RFC 5280, §4.2.1.6. Certificate Transparency — crt.sh. Let's Encrypt rate limits — letsencrypt.org/docs/rate-limits.