What is a wildcard certificate?

A wildcard certificate covers every hostname at one level of a domain: *.example.com matches app.example.com, api.example.com, and any other single label in that position. It is the standard answer to "we create subdomains faster than we want to issue certificates," because a new subdomain is covered the moment it exists.

The scope rules are strict and worth knowing precisely. The wildcard matches exactly one label: *.example.com does not cover example.com itself, and it does not cover a.b.example.com, because the asterisk cannot span a dot. Certificates therefore usually pair the wildcard with the bare domain in the SAN list, and a second-level wildcard (*.b.example.com) needs its own certificate. The asterisk is only valid as the entire leftmost label; forms like a*.example.com are not issued by public CAs.

Issuance is more demanding than for a normal certificate. No public CA will issue a wildcard from a simple HTTP file check — validation has to prove control of the domain itself, via DNS or, at some commercial CAs, an email to the domain's registered contact. For ACME CAs such as Let's Encrypt that means the DNS-01 challenge, proving control of the domain's DNS zone, not just its web server. That requirement is what makes wildcard automation harder: your renewal tooling needs API access to your DNS provider, and DNS API credentials on a server are themselves something to protect.

The trade-off to weigh is blast radius. One wildcard means one private key deployed to every server that terminates TLS for any subdomain. If any of those hosts is compromised, the key impersonates all of them. Teams that keep wildcards operate them like shared secrets: few copies, short lifetimes, fast rotation. Teams that prefer per-hostname certificates accept more issuance in exchange for smaller failure domains. Neither answer is wrong; issuing a wildcard because it is convenient and then copying the key to twenty servers is.