Definition

A wildcard certificate is a TLS/SSL certificate that covers all first-level subdomains of a domain, using a single wildcard character * in the Common Name (CN) or Subject Alternative Name (SAN).

Example: a certificate issued for *.example.com is valid for:

  • example.com (with many issuers, the root must also be included explicitly)
  • www.example.com
  • api.example.com
  • app.example.com
  • anything.example.com

It does not cover:

  • sub.sub.example.com (only one level of wildcard)
  • other-domain.com

Syntax and standard

The wildcard is represented by the asterisk * in the leftmost label of the DNS name (RFC 6125, RFC 2818). The CA issues the certificate for an FQDN such as:

*.example.com

In modern certificates, names are listed in Subject Alternative Names (SAN). A typical wildcard certificate may have:

  • *.example.com
  • example.com (root domain, if the CA includes it)

The legacy CN may contain *.example.com, but browsers and libraries use SAN for validation. Without the root domain in SAN, https://example.com may not be considered covered by the wildcard in some implementations.

When to use

ScenarioReason
Multiple subdomainsOne certificate for api, app, admin, staging, etc., without issuing a cert per subdomain.
Dynamic subdomainse.g. SaaS where each customer has customer.yourdomain.com; one wildcard covers all.
Environments (dev/staging)dev.company.com, staging.company.com with the same cert.
CDN / multi-originVarious hostnames under the same domain pointing to the same infra.

Reduces operational cost (fewer certificates to renew) and simplifies deployment when there are many hostnames.

Technical limitations

  1. One level only
    *.example.com covers a.example.com, not a.b.example.com. For that you need a multi-SAN certificate or another wildcard for *.b.example.com.

  2. Does not cover the root by default
    Many CAs require you to explicitly include example.com (without wildcard) in the request; otherwise, https://example.com may fail validation.

  3. Domain validation
    For wildcards, the CA normally requires DNS validation: you create a TXT (or CNAME) record on the domain to prove control. HTTP file validation does not work for *, because the CA does not know which URL to use for the file.

  4. EV (Extended Validation)
    EV wildcard certificates exist but are rare and expensive; most wildcards are OV (Organization Validation) or DV (Domain Validation).

Security and risks

  • Compromise: If the wildcard private key is leaked, all covered subdomains are compromised. Therefore:
    • Store the key in an HSM or vault (e.g. AWS ACM, HashiCorp Vault).
    • Restrict access to the key and rotation.
  • Renewal: Wildcards usually have a validity of up to 1 year (CA policy). Automate renewal (e.g. certbot, ACM, Let’s Encrypt) to avoid expiration.
  • Audit: Knowing where the wildcard is installed is harder than with per-hostname certs; keep an inventory.

Practical example: Let’s Encrypt wildcard

With certbot and DNS validation (plugin for your DNS provider):

# DNS validation (required for wildcard)
certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d "*.example.com" \
  -d "example.com"

You receive a TXT challenge to create at _acme-challenge.example.com. After the CA validates, the certificate is issued for *.example.com and (if requested) example.com.

Summary

AspectDetail
What it isTLS certificate that covers all one-level subdomains (*.domain.com).
AdvantageOne cert for many hostnames; useful for SaaS, APIs, environments.
LimitationOnly one wildcard level; DNS validation; care needed with key leakage.
PracticeInclude root domain in SAN when needed; automate renewal and protect the private key.

Using a wildcard is an operations and risk decision: it simplifies management but requires strong controls on where the key is used and how it is stored.