Wildcard vs SAN vs Single-Domain SSL Certificates

Every SSL certificate has a list of hostnames it's valid for. The simplest case — a single hostname like example.com — is what most people think of when they think of an SSL cert. But certificates can also cover multiple specific hostnames (SAN certificates) or every subdomain of a parent (wildcard certificates). Each option exists because different sites have different needs, and choosing the right one means thinking about how your domains will grow over the next few years.

Single-Domain Certificates

A single-domain certificate covers exactly one hostname. example.com only — not www.example.com, not blog.example.com, not example.com:8443. One hostname, one cert.

In practice, almost no certificate is truly "single domain" today. Even the most basic Let's Encrypt or paid DV certificate typically covers both the apex (example.com) and the www subdomain (www.example.com) by default — that's technically a SAN certificate with two names, but most people still call it a "single domain" cert because it covers one website.

This is the right choice when:

• You only have one site and one or two hostnames to cover.
• You don't expect to add new subdomains.
• You want the absolute minimum attack surface — fewer hostnames on the cert means less to worry about.

Cost: free with Let's Encrypt, or $10–$80 a year for a paid DV.

Multi-Domain (SAN) Certificates

A SAN (Subject Alternative Name) certificate lists multiple specific hostnames in the certificate's SAN extension. Browsers consider the certificate valid for any hostname on that list — but only those exact hostnames, not subdomains of them.

SAN certs are useful when you have several distinct sites that should share infrastructure but live on different domains. For example:

• example.com
• www.example.com
• example.co.uk
• example.org
• blog.example.com
• shop.example.com

One certificate, six hostnames. Behind the scenes, each hostname needs to be validated separately during issuance — for Let's Encrypt, that means each one needs to pass an HTTP or DNS challenge.

Let's Encrypt supports up to 100 SANs per certificate at no charge. Paid CAs typically charge per additional SAN — common pricing is something like $80 base price plus $20 per additional SAN, so a 6-SAN cert from a paid CA could be $180–$300 a year.

This is the right choice when:

• You run multiple distinct websites or domains that share a server.
• You have a small, known list of hostnames that doesn't change often.
• You want all your hostnames covered by one certificate with one renewal cycle.

Wildcard Certificates

A wildcard certificate covers a parent domain and every direct subdomain of it. *.example.com is valid for www.example.com, blog.example.com, api.example.com, anything-you-spin-up-tomorrow.example.com.

The key word is "direct" — wildcards only cover one level. *.example.com does not cover blog.users.example.com; you'd need *.users.example.com for that. And the wildcard does not cover the apex domain itself — *.example.com is not valid for example.com. To cover both, you typically issue the certificate with example.com and *.example.com as two SANs (Let's Encrypt supports this directly).

Wildcards have one practical constraint: they require DNS-based validation. The HTTP-01 challenge that's used for normal Let's Encrypt issuance can't validate "every possible subdomain" — there's no way to prove control of every *.example.com via HTTP. So you need DNS-01: the ACME client adds a TXT record to your DNS to prove control. This means your DNS provider needs to support API-based record updates. Cloudflare, Route 53, DigitalOcean, Linode, and most modern providers do; some legacy providers don't.

Wildcards are the right choice when:

• You run a SaaS with tenant subdomains (customer1.example.com, customer2.example.com).
• You add new subdomains often and don't want to reissue the certificate every time.
• You have ten-plus subdomains under one parent.

Cost: free with Let's Encrypt. Paid CAs typically charge $100–$300+ a year for a wildcard, which is one of the strongest arguments for using Let's Encrypt for any site that needs wildcards.

The Security Trade-off

The bigger the certificate's scope, the worse a private key compromise is.

• If a single-domain cert's key leaks, an attacker can impersonate that one hostname until you revoke and reissue.
• If a SAN cert's key leaks, the attacker can impersonate every hostname on the cert.
• If a wildcard cert's key leaks, the attacker can impersonate any subdomain of the wildcard parent — including subdomains that didn't even exist when the cert was issued.

This isn't theoretical. Wildcard private keys often get distributed widely — the same key file ends up on every server that handles any subdomain, every developer's laptop for testing, every CI runner, every infrastructure-as-code repo. Each of those is a place the key could leak.

If you use a wildcard:

• Restrict the key to as few systems as possible.
• Treat the key file like a password — never commit it to a git repo, never email it, never paste it into a chat.
• Renew often. With Let's Encrypt's 90-day cert lifetime, even a stolen key has a hard expiry.
• If you suspect compromise, revoke and reissue with a new key immediately. Don't wait for renewal.

If your subdomain count is small (say, fewer than 20), a SAN certificate gives you much of the convenience of a wildcard with a smaller blast radius if something goes wrong.

Mixing Approaches

You don't have to choose just one. Common patterns:

• Wildcard for tenant subdomains, SAN for marketing. A SaaS might have a wildcard *.app.example.com for tenants and a separate SAN cert for example.com, www.example.com, blog.example.com, docs.example.com. Each cert has a smaller blast radius than one giant wildcard for everything.
• Per-service certificates. Issue a separate certificate for each subdomain. This is the strongest isolation — a key compromise affects only one service. Modern automation (Caddy, Traefik, Kubernetes cert-manager) makes this practical at scale where it would have been a renewal nightmare a decade ago.
• Wildcard for production, single-domain for high-value services. Use a wildcard for general infrastructure but issue dedicated certs for sensitive services like payment processing or admin tools.

How to Tell What You Have

Run any domain through SSL Checker and look at the SAN list in the report. If you see:

• One or two specific hostnames (example.com, www.example.com) — single-domain or basic two-name SAN.
• A short list of specific hostnames — multi-domain SAN.
• An entry starting with * (e.g. *.example.com) — wildcard.
• A long list of unrelated hostnames — possibly a shared CDN certificate (Cloudflare, Fastly, AWS) where many customers share one cert. This is normal for sites behind those CDNs and isn't a problem.

The Recommendation

Most sites are best served by a basic SAN covering example.com and www.example.com — that's the default Let's Encrypt issues, and it's free.

If you have a small known set of subdomains, add them as SANs (still free, still one cert).

If you spin up subdomains regularly or run tenant subdomains in a SaaS, switch to a wildcard. Use Let's Encrypt with DNS-01 validation, keep the private key tightly held, and renew on schedule.

For high-security services or anything that must be isolated from the rest of your infrastructure, issue a dedicated single-domain certificate with its own keypair.

Whatever you pick, run a regular SSL Checker scan to confirm the cert covers the hostnames you actually serve and the chain is complete.