What is a wildcard certificate?
A wildcard certificate is a TLS certificate whose name starts with an asterisk as the entire leftmost label, such as *.example.com. It is valid for any hostname that fills that one position: www.example.com, mail.example.com, vpn.example.com and any subdomain added later at the same level. One certificate and one private key then cover many servers, which is why wildcards are popular with organizations that create subdomains often.
What a wildcard covers
The asterisk matches exactly one DNS label, the text between two dots. That rule produces the cases that catch people out:
| Hostname | Covered by *.example.com? |
|---|---|
| shop.example.com | Yes |
| example.com (the apex) | No, nothing fills the asterisk |
| api.dev.example.com | No, that is two labels |
| shop.example.org | No, a different domain |
Many CAs add the bare domain as a second Subject Alternative Name entry, so a certificate sold as a wildcard often lists both *.example.com and example.com. In that case the apex is covered by the second entry, not by the asterisk. A client that connects with a name the certificate does not cover shows a name mismatch error, such as Chrome's NET::ERR_CERT_COMMON_NAME_INVALID.
Benefits and risks
Wildcards reduce certificate management, since new subdomains need no new certificate. They also keep individual hostnames out of public Certificate Transparency logs, because only *.example.com is published. The cost is concentrated risk:
- The same private key sits on every server that uses the certificate, so the least protected machine, perhaps a forgotten test box, holds a key that can impersonate every subdomain.
- If that key is compromised, revoking the certificate breaks every site that shares it at once.
- Extended validation (EV) certificates cannot be wildcards at all.
To limit exposure, many teams terminate TLS for all subdomains on a load balancer or reverse proxy, so the wildcard key lives in one well-guarded place. Let's Encrypt, for example, issues a wildcard only after a DNS-based challenge. A domain owner who never wants wildcards issued can publish a CAA record with an issuewild tag that forbids them.
Wildcard vs. SAN certificate
A SAN certificate, also called a multi-domain certificate, lists specific names in its Subject Alternative Name extension, and those names can come from unrelated domains or sit at different depths: example.com, example.net and api.dev.example.com can share one certificate. A wildcard covers unlimited names at one level of one domain and nothing else. The two can be combined, since a SAN list may include a wildcard entry alongside specific names. Both share one key across every name they cover, and changing a SAN list means reissuing the certificate.
Wildcard certificate on the CompTIA Security+ exam
Wildcard certificates are named in SY0-801 objective 1.3, among the certificate choices you need to explain. Wording such as "many subdomains of one domain", "new subdomains are added every month" or "reduce the number of certificates to manage" points to a wildcard. Read every hostname in the question: if the list includes the apex, a second domain or a deeper name, a wildcard alone is the wrong answer and a SAN certificate fits better. Distractors include self-signed certificates, which change who trusts the certificate rather than which names it covers, and code signing certificates, which identify software publishers rather than servers.