Wildcard SSL certificates explained (and when to use one)

A wildcard SSL certificate secures every host at a single label level under one domain, so *.example.com covers www.example.com, api.example.com, and shop.example.com from one certificate and one private key. That convenience is also where people trip up: a wildcard does not cover the bare domain itself, it does not reach two levels deep, and it concentrates risk in a single key. This guide explains exactly what a wildcard covers, how it gets validated, when it beats a multi-domain (SAN) certificate, and when you should deliberately avoid one.

What a wildcard certificate actually covers

The wildcard is the * in the leftmost label of the name. *.example.com matches any single label in that position:

*.example.com  matches:
  www.example.com
  api.example.com
  shop.example.com
  staging.example.com

The matching is purely about labels (the dot-separated segments of a hostname), and the wildcard only ever occupies the leftmost one. Everything to the right of the * must match literally. That single rule explains both what a wildcard does and the two things it pointedly does not do.

It does not cover the apex domain

This is the limitation people get wrong most often. *.example.com does not match example.com itself. The apex (also called the root or naked domain) has no label where the * would sit, so it falls outside the wildcard entirely. If you serve your site at the bare example.com and your certificate only lists *.example.com, browsers reject it with a name-mismatch error like ERR_TLS_CERT_ALTNAME_INVALID, even though the certificate is perfectly valid and unexpired.

The fix is to add the apex as its own Subject Alternative Name (SAN) alongside the wildcard. A correctly issued certificate for a site that lives at both names carries two SANs:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:*.example.com

Most CAs, including Let's Encrypt, let you request the apex and the wildcard together for no extra charge. With certbot you simply pass both names:

certbot certonly --manual --preferred-challenges dns \
  -d 'example.com' -d '*.example.com'

Verify the result covers both by dumping the SANs from the issued cert:

openssl x509 -noout -ext subjectAltName \
  -in /etc/letsencrypt/live/example.com/fullchain.pem

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:*.example.com

If example.com is missing from that list, the apex is unprotected no matter how many subdomains the wildcard sweeps up.

It does not cover deeper labels

A wildcard matches exactly one label, not a whole subtree. *.example.com covers api.example.com but not v2.api.example.com, because that name has an extra label between the host and the domain. To secure a level deeper you need a wildcard scoped to that parent:

*.example.com    covers  api.example.com
*.api.example.com  covers  v2.api.example.com, edge.api.example.com

There is no *.*.example.com in the public CA world — a certificate may contain only one wildcard label, and it has to be the leftmost one. If you have multiple subdomain depths, you either issue a separate wildcard per level or list the specific deep hostnames as SANs.

How a wildcard is validated

To prove you control every possible host under *.example.com, a CA cannot ask you to put a file on one specific server — there is no single server, the wildcard stands in for all of them. So wildcard issuance requires the DNS-01 challenge, where you prove control of the domain by publishing a TXT record the CA dictates.

For Let's Encrypt this is a hard requirement: you can issue a wildcard with DNS-01, and only DNS-01. The HTTP-01 challenge (dropping a token at http://example.com/.well-known/acme-challenge/...) is not accepted for wildcards, because proving control of one HTTP endpoint does not prove control of every host the wildcard would cover.

The manual flow with certbot prompts you to create a TXT record:

certbot certonly --manual --preferred-challenges dns \
  -d 'example.com' -d '*.example.com'

Please deploy a DNS TXT record under the name:
_acme-challenge.example.com
with the following value:
gfj9Xq...Rg85nM

You publish that _acme-challenge.example.com TXT record, let DNS propagate, and certbot completes the order. The manual approach works once but is painful to renew, since the TXT value changes every time. For anything you intend to keep, use a DNS plugin that talks to your provider's API and writes the record automatically:

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d 'example.com' -d '*.example.com'

Plugins exist for most major DNS providers (Cloudflare, Route 53, Google Cloud DNS, DigitalOcean, and others), and each handles creating and tearing down the challenge record so unattended renewal works. After issuing, confirm the dates and names the way you would for any certificate — see how to check an SSL certificate with OpenSSL for the full set of flags, and how to renew an SSL certificate for keeping the renewal automated.

Wildcard vs. SAN (multi-domain) vs. single-domain

Three certificate types cover overlapping needs, and the right choice depends on how your hostnames are shaped.

| Type | Covers | Best when | |---|---|---| | Single-domain | One exact name (often plus www) | You have one or two stable hostnames | | SAN / multi-domain | An explicit list of names, possibly across different domains | You have a known, finite set of hosts — including different apex domains | | Wildcard | Every host at one label level under a domain | You add or change subdomains often and don't want to reissue each time |

The deciding question is whether your set of names is finite and known or open-ended. A SAN certificate lists each name explicitly, which means every new subdomain requires reissuing the certificate — fine if your hostnames rarely change, and the only option when you need to cover several different registered domains on one cert. A wildcard trades that explicitness for flexibility: spin up feature-123.example.com tomorrow and the existing wildcard already covers it, no reissue needed. The two are not mutually exclusive — a certificate can carry both literal SANs and a wildcard, which is exactly how you cover the apex plus all subdomains in one cert.

If your hostnames don't move and you only run a handful, a plain single-domain certificate (with www as a second SAN) is the least error-prone choice. Reach for a wildcard when the subdomain churn, not the domain count, is what's driving you.

The security trade-off of one shared key

A wildcard's convenience comes from one certificate and one private key standing in for every subdomain. That same property enlarges your blast radius.

• Key compromise is total. If the private key behind *.example.com leaks — pulled from a misconfigured server, a backup, or a build artifact — an attacker can impersonate every host under that domain, not just the one machine that leaked it. With per-host certificates, a single leaked key compromises a single host.
• Revocation is all-or-nothing. Because every subdomain shares the certificate, revoking it after a compromise kills TLS for all of them at once. You cannot revoke staging.example.com without taking down www, api, and everything else the wildcard serves.
• Wide distribution defeats isolation. To serve a wildcard from many machines, the same private key has to be copied to all of them. The more places a key lives, the more places it can leak from. Each load balancer, container image, and CDN edge that holds the key is another exposure point.

None of this makes wildcards unsafe to use — it makes them something to scope deliberately. Keep the wildcard key off hosts that don't need it, and give genuinely sensitive endpoints their own dedicated certificate and key so a compromise elsewhere can't reach them.

Cost: paid CAs vs. Let's Encrypt

Historically the wildcard was a premium product. Commercial CAs charge a meaningful markup for *.example.com over a single-domain cert, because one wildcard replaces what would otherwise be many individual certificates, and pricing reflects that leverage.

Since 2018, Let's Encrypt issues wildcards for free via the DNS-01 challenge through the ACME v2 API. If you can automate a TXT record with your DNS provider, there is no longer a cost argument for buying a wildcard. The paid-CA case today is mostly about extended validation, support contracts, warranty terms, or organizational policy — not the wildcard capability itself. For most teams, a free Let's Encrypt wildcard renewed by a DNS plugin is the pragmatic default.

When not to use a wildcard

A wildcard is the wrong tool when isolation matters more than convenience.

• PCI and other compliance isolation. If a host handles cardholder data or other regulated information, you generally want it cryptographically isolated from the rest of your estate. Sharing a wildcard key across your payment host and your marketing subdomains undercuts that isolation; give the sensitive host its own certificate and key.
• Untrusted or multi-tenant subdomains. If customers, partners, or untrusted services control subdomains under your domain — tenant1.example.com, tenant2.example.com — a single wildcard key sitting on shared infrastructure is a liability. One tenant's compromise should not hand over a key valid for every tenant. Per-tenant certificates (often automated with ACME at provisioning time) keep blast radius contained.
• Hosts with very different lifecycles or owners. If two subdomains are managed by different teams on different release schedules, a shared certificate forces a shared revocation and renewal fate. Separate certs let each team move independently.

The common thread: whenever the cost of one key compromising many hosts is unacceptable, the wildcard's central feature becomes its central risk.

Monitoring expiry across many subdomains

A wildcard hides a subtle operational trap: the expiry date lives on one certificate, but the consequences land across every subdomain at once. When *.example.com expires, www, api, app, and every other host fail simultaneously, often outside business hours. And because all those subdomains share a cert, it's easy to forget any of them are tied to a renewal that quietly failed.

Don't rely on memory or on checking one subdomain by hand. Watch the certificate that backs them, and confirm it still covers both the apex and the wildcard SAN after each renewal — a reissue that dropped the apex looks fine on www and breaks the bare domain. For a one-off look, the hosted SSL check tool reports the expiry, issuer, and SANs from outside your network. For the full operational picture — chain, hostname match, and alert lead times — see the complete guide to SSL certificate monitoring.

Monitor it automatically

SSLNudge checks the certificate behind your wildcard every day, well before it expires, so a single renewal failure doesn't take down every subdomain at once. It verifies the SAN list too, catching the classic case where a reissued wildcard quietly drops the apex. Add your domain once and let the daily check watch it for you. Sign in to start monitoring.