A wildcard certificate includes a Subject Alternative Name entry such as *.example.com, letting a single certificate cover any single-label subdomain. They reduce certificate management overhead but concentrate risk: one private key, one blast radius.
The asterisk in a wildcard SAN matches exactly one DNS label. *.example.com covers www.example.com, api.example.com, and mail.example.com — any immediate subdomain. It does not match:
example.com itself is not covered. A wildcard entry and an explicit apex entry must both appear in the SAN list if you need to cover both.sub.api.example.com is not matched by *.example.com. You would need a separate certificate or a deeper wildcard such as *.api.example.com.X509v3 Subject Alternative Name:
DNS:example.com, DNS:*.example.com
The two-entry pattern above covers both the apex and all direct subdomains.
The central tradeoff with wildcard certificates is operational convenience versus security blast radius. A single private key authenticates every hostname in the wildcard's scope. If that key is stolen — through a server compromise, a misconfigured deployment pipeline, or an insider — every subdomain must be treated as compromised and a replacement certificate issued immediately across all services using it.
Per-hostname certificates, by contrast, limit an individual key compromise to a single service. The operational overhead is higher, but short-lived certificates from an automated CA (such as Let's Encrypt with ACME) reduce that burden significantly. Many organizations use wildcard certs for internal staging environments where the blast radius is acceptable, and per-host certs for externally facing production services.
Let's Encrypt and most public CAs require the DNS-01 ACME challenge to issue wildcard certificates. Unlike the HTTP-01 challenge (which proves control by serving a file over HTTP), DNS-01 proves control by placing a specific TXT record in your domain's DNS zone. This requirement exists because wildcard certificates assert authority over an entire subdomain namespace, and only DNS control unambiguously demonstrates that authority.
The DNS-01 requirement means wildcard certificate automation requires write access to your DNS provider's API, which introduces its own credential-management surface to secure.
A CAA record can restrict which CAs may issue wildcard certificates for your domain separately from non-wildcard issuance. The issuewild CAA property controls wildcard authorization, while the issue property controls non-wildcard issuance. If you publish a issuewild record naming only a specific CA, other CAs must refuse wildcard requests for that domain.
Inspect wildcard certs with the TLS tool
Open TLS Inspector