What Is a Wildcard SSL Certificate?

What a Wildcard Certificate Is

A wildcard SSL/TLS certificate secures a domain and its direct subdomains with a single certificate, using an asterisk as the leftmost label:

*.example.com

One certificate, one private key, one renewal — covering every subdomain one level below example.com, including subdomains that did not exist when the certificate was issued.

Exactly What It Covers

Wildcard matching is defined by RFC 6125 and enforced by browsers. The asterisk replaces exactly one label, and only the leftmost one.

The two rows that catch people out are the bare domain and the multi-level subdomain. Both are covered below.

The Bare Domain Problem

*.example.com does not match example.com. This surprises almost everyone the first time, and it produces a hard browser error on the apex:

NET::ERR_CERT_COMMON_NAME_INVALID

The fix is to include both names in the certificate's Subject Alternative Name (SAN) list:

DNS:*.example.com
DNS:example.com

Practically every CA issues this pair as a matter of course, and Let's Encrypt does it when you request both names. If you inherited a certificate that fails on the apex, check the SAN list before assuming the certificate is broken — it is more likely incomplete.

The Multi-Level Problem

*.example.com does not cover sub.api.example.com. A second wildcard entry is required:

DNS:*.example.com
DNS:*.api.example.com

Certificates with a wildcard in a position other than the leftmost label — www.*.example.com, *.*.example.com — are not accepted by browsers. If you need arbitrary depth, you need one wildcard entry per level you intend to serve.

Public Suffix Restriction

No CA will issue *.com, *.co.uk, or a wildcard on any entry in the Public Suffix List. A wildcard must sit below a registrable domain that you control.

Wildcard vs the Alternatives

A wildcard cannot cover a second registered domain. *.example.com will never serve example.net — that requires additional SAN entries or a separate certificate.

Advantages

• One renewal instead of many. A single expiry date to monitor rather than one per subdomain.
• New subdomains work immediately. Spin up feature-42.example.com and it is already covered — no issuance, no ACME round trip, no wait.
• Fewer moving parts in automation. One certificate to distribute to load balancers and origin servers.
• Subdomain names stay out of Certificate Transparency logs. Every non-wildcard certificate is published to public CT logs, which means issuing admin.example.com announces that hostname to anyone watching. A wildcard publishes only *.example.com. This is a real, if modest, reduction in reconnaissance surface — it is not a security control, because subdomains are discoverable by other means, but it does close one easy channel.

Limitations and Risks

• One key compromises everything. The blast radius of a stolen private key is every subdomain the wildcard covers, not one hostname. This is the central trade-off.
• The key must exist wherever the certificate is served. If ten teams each run their own subdomain on their own infrastructure, a wildcard means distributing one private key to ten places. Each copy is another chance to leak it.
• Revocation is all-or-nothing. Revoking a compromised wildcard invalidates every subdomain at once. With per-host certificates you revoke one and the rest keep serving.
• No apex coverage without an explicit SAN, as above.
• Some environments restrict them. Certain managed platforms and internal PKI policies disallow wildcards outright.

Free Wildcards with Let's Encrypt

Let's Encrypt issues wildcard certificates through ACMEv2, with one important constraint: wildcard issuance requires the DNS-01 challenge. The HTTP-01 challenge used for ordinary certificates is not accepted for wildcards, because serving a file over HTTP proves control of one host, not of the whole namespace below the domain.

The DNS-01 flow:

1. Your ACME client requests a certificate for *.example.com.
2. Let's Encrypt returns a token.
3. The client creates a TXT record at _acme-challenge.example.com containing a value derived from that token.
4. Let's Encrypt queries that TXT record from the public DNS system.
5. On a match, the certificate is issued and the TXT record can be removed.

Step 3 is why wildcards need more setup than standard certificates: something must write a DNS record automatically. Certbot and acme.sh both ship DNS plugins for the major providers, which authenticate to the provider's API and manage the record for you:

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

Note that both names are requested — the apex and the wildcard — so the resulting certificate covers example.com as well.

Practical points worth knowing before you automate this:

• Renewal repeats the DNS challenge. Certificates last 90 days, so whatever writes the TXT record must keep working unattended. A manual DNS edit at issuance time creates a certificate that silently fails to renew.
• Two names in one order need two TXT records. Requesting the apex and the wildcard together produces two challenges at the same _acme-challenge.example.com name. The DNS provider must support multiple TXT values on one name; nearly all do, but some caching layers do not return both.
• Propagation delay causes most failures. If validation runs before the TXT record is visible to Let's Encrypt's resolvers, the order fails. Most plugins expose a wait interval for exactly this reason.
• Rate limits apply per registered domain. Repeated failed attempts while debugging count against the limit, so test against the staging endpoint first.

When to Use a Wildcard — and When Not To

Use one when:

• You have many subdomains, or create them dynamically (per-customer, per-branch, per-environment).
• All covered subdomains terminate TLS on infrastructure under the same operational control.
• You have a real answer to "where does the private key live, and who can read it?"

Avoid one when:

• Subdomains run on infrastructure you do not control, or that different teams administer with different security postures.
• You need compartmentalisation — the ability to revoke or rotate one service without touching the others.
• A third party (a SaaS vendor hosting status.example.com, for instance) would need a copy of the key. Give them their own certificate instead.

The rule of thumb: a wildcard is a convenience decision with a security cost, and the cost scales with how many separate places the private key ends up.

Troubleshooting

Frequently Asked Questions

Does a wildcard certificate slow down TLS handshakes? No. Certificate coverage has no effect on handshake performance. Chain length and key algorithm do.

Can I use one wildcard certificate on several servers? Technically yes — the certificate and its key can be installed anywhere. Whether you should depends entirely on whether you trust every one of those servers with the key.

Do wildcards work for email and other TLS services? Yes. A wildcard is an X.509 certificate like any other and can secure SMTP, IMAP, or any service on a covered hostname.

Is a wildcard less trusted by browsers? No. Validation level (DV, OV, EV) is independent of wildcard coverage, and browsers treat a DV wildcard exactly as they treat a DV single-name certificate.

Verify which names a certificate actually covers, and how long it has left, with the SSL Certificate Checker. To confirm the DNS-01 TXT record has propagated before an ACME run, use the DNS Lookup tool. For monitoring expiry across an estate, see How to Check SSL Certificate Expiry.