# Wildcard SSL certificates: what they cover, and when not to use one

A wildcard certificate for `*.example.com` is valid for any single name
directly under `example.com`. It's convenient: one certificate for
`www`, `mail`, `vpn` and any subdomain you add later. It also comes with
limits people regularly trip over, and a security trade-off.

## What `*.example.com` covers

The wildcard matches exactly **one** label, and must be the whole
leftmost label:

| Name | Covered by `*.example.com`? |
|---|---|
| `www.example.com` | Yes |
| `vpn.example.com` | Yes |
| `example.com` | **No** |
| `dev.app.example.com` | **No** |

To cover the bare domain, the certificate needs both names:
`example.com` and `*.example.com` (most CAs and ACME clients add both
when asked). For `*.app.example.com`, you need a second wildcard.

Extended Validation (EV) certificates can't be wildcards at all.

## Getting one free

Let's Encrypt issues wildcards, but only with the **DNS-01** challenge:
you prove control by creating a TXT record at `_acme-challenge.example.com`.
The usual HTTP check can't be used for wildcards.

To renew automatically, the ACME client needs API access to your DNS
provider (certbot DNS plugins, acme.sh, Caddy, cert-manager and others
support the common ones). With lifetimes shrinking to 200 days now, 100
days from March 2027 and 47 days from March 2029, a wildcard renewed by
hand is a recurring outage waiting to happen: see
[47-day SSL certificates](/guides/47-day-ssl-certificates).

## The trade-offs

**One key, many servers.** A wildcard installed on the website, the
firewall, the mail server and a contractor's staging box shares one
private key across all of them. If any one of them is compromised, the
attacker can impersonate every subdomain, and you have to replace the
certificate everywhere at once.

**Every copy must be renewed.** The same certificate on five devices is
five installs per renewal. Miss one and it expires on its own schedule:
the classic [renewed but not installed](/guides/certificate-renewed-but-not-installed)
outage.

**Hidden hostnames.** CT logs record `*.example.com`, not the hosts that
use it. That keeps internal names out of public logs, but it also means a
CT search won't tell you where the certificate is installed. Keep your own
list.

## When a wildcard makes sense

- Many short-lived or customer-specific subdomains on **one** platform
  (`customer1.app.example.com`), served by a load balancer or CDN that
  renews automatically.
- A CDN or hosting platform that manages the wildcard for you.

## When to use separate certificates

- Appliances: firewalls, VPNs, RD Gateway, mail servers. Give each its own
  certificate and key.
- Anything that a third party runs or that you'd revoke on its own.
- When automation is available per host anyway: with ACME, a certificate
  per name costs nothing extra.

## Check your domain

The [certificate finder](/tools/find-ssl-certificates) lists every
certificate in CT logs for your domain, wildcards included, and the
[SSL expiry checker](/tools/ssl-expiry-checker) shows what each host is
actually serving and when it expires.

## Sources

- [CA/Browser Forum: Baseline Requirements (1.6.1 definitions, 3.2.2.6, 6.3.2)](https://cabforum.org/working-groups/server/baseline-requirements/requirements/)
- [CA/Browser Forum: EV Guidelines (7.1.2.1, 7.1.4.2.2)](https://cabforum.org/working-groups/server/extended-validation/guidelines/)
- [RFC 9525: Service identity in TLS (6.3 wildcards)](https://www.rfc-editor.org/rfc/rfc9525)
- [Let's Encrypt: FAQ](https://letsencrypt.org/docs/faq/)
- [Let's Encrypt: Challenge types](https://letsencrypt.org/docs/challenge-types/)

---
Source: https://nameward.app/guides/wildcard-ssl-certificates (updated 2026-10-31)