Wildcard SSL Certificates Explained

A wildcard SSL certificate covers an unlimited number of subdomains with a single certificate. Instead of buying separate certificates for www.example.com, api.example.com, app.example.com, and every other subdomain, a wildcard cert for *.example.com covers them all. It's convenient, cost-effective, and one of the most misunderstood certificate types.

Here's how wildcards actually work, where they fall short, and when you should -- or shouldn't -- use one.

How Wildcard Certificates Work

A wildcard certificate uses an asterisk (*) in the domain name to match any single-level subdomain. The certificate for *.example.com is valid for:

• www.example.com
• api.example.com
• staging.example.com
• anything.example.com
• Any other single subdomain of example.com

The asterisk replaces exactly one level of subdomain. That's the key detail most people miss.

What Wildcards Don't Cover

The * is not a universal catch-all. There are important limitations:

Multi-level subdomains are not covered. A certificate for *.example.com does NOT cover:

• sub.api.example.com
• dev.staging.example.com
• a.b.example.com

Each level of subdomain needs its own wildcard. To cover *.staging.example.com, you'd need a separate wildcard certificate (or a SAN entry for that specific pattern).

The bare domain is not automatically covered. A certificate for *.example.com does NOT automatically cover example.com (without a subdomain). Most certificate authorities include the bare domain as a Subject Alternative Name (SAN), but this is a convention, not a guarantee. Always verify that the bare domain is listed in the SANs.

When to Use Wildcard Certificates

Wildcards make sense in several scenarios:

The Security Risks of Wildcards

Wildcards are convenient, but they come with real security trade-offs that are worth understanding before you deploy one.

One Key to Rule Them All

The biggest risk: a wildcard certificate uses a single private key for every subdomain. If that key is compromised, an attacker can impersonate any subdomain on your domain -- not just the one that was breached.

With individual certificates, a compromised key affects only one subdomain. With a wildcard, the blast radius is your entire domain.

Key Distribution Challenges

If you have multiple servers handling different subdomains, you need to deploy the same private key to all of them. Every server that needs the wildcard certificate gets a copy of the private key. More copies mean more exposure.

Consider: your marketing site, your API server, your staging environment, and your internal tools all sharing the same private key. If the staging server gets compromised (and staging servers are often less hardened), the attacker has a valid key for your production API.

Revocation Is All-or-Nothing

If you need to revoke a wildcard certificate (because the key was compromised), you revoke it for every subdomain simultaneously. You then need to reissue and redeploy across every server. With individual certificates, you revoke and replace only the affected subdomain.

Alternatives to Wildcard Certificates

SAN (Subject Alternative Name) Certificates

A SAN certificate lists multiple specific domains and subdomains. Instead of a wildcard, you explicitly name each domain the certificate covers:

DNS: example.com
DNS: www.example.com
DNS: api.example.com
DNS: app.example.com

Pros: More precise control, no wildcard security risks, can span different domains (not just subdomains).

Cons: You need to know all your subdomains in advance and update the certificate when adding new ones.

Individual Certificates Per Subdomain

With Let's Encrypt, issuing a separate certificate for each subdomain is free and automated. Each subdomain gets its own key pair, limiting the blast radius of any compromise.

Pros: Best security isolation, simple per-service management, free with Let's Encrypt.

Cons: More certificates to manage and monitor. This scales well with automation but becomes burdensome without it.

Cost Comparison

Let's Encrypt has significantly changed the cost equation. When certificates are free, the main reason to use a wildcard is management simplicity, not cost savings.

Wildcard Certificates with Let's Encrypt

Let's Encrypt supports wildcard certificates, but with one important requirement: you must use DNS-01 validation. HTTP-01 validation (the simpler challenge type) doesn't work for wildcards.

DNS-01 validation requires creating a TXT record in your domain's DNS. This means your ACME client (Certbot, acme.sh, etc.) needs API access to your DNS provider.

# Request a wildcard certificate with Certbot
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "*.example.com" \
  -d "example.com"

Supported DNS plugins for Certbot include: Cloudflare, Route 53, Google Cloud DNS, DigitalOcean, and many others. If your DNS provider doesn't have a plugin, you can use manual DNS validation, but that breaks auto-renewal.

Monitoring Wildcard Certificates

Wildcard certificates have a single expiry date that affects every subdomain. If the certificate expires or is misconfigured on any server, all subdomains on that server go down simultaneously.

This makes monitoring especially important:

• Monitor the certificate itself -- one expiry date, but high impact if missed
• Monitor deployment across servers -- the same certificate might be deployed to multiple servers; check each one
• Monitor for inconsistencies -- if one server gets updated and another doesn't, you'll have mismatched certificates

Because a wildcard failure is a domain-wide failure, the consequences of missing a renewal are amplified. One expired certificate takes down everything, not just one subdomain.

A wildcard certificate is a powerful tool. Just remember: with great convenience comes great responsibility.