A wildcard SSL certificate is a TLS certificate issued for a name like *.example.com, so one certificate and one private key secure every first-level subdomain: www, api, shop and any name you add later. It does not cover a.b.example.com, and the bare example.com is covered only if listed separately.
What does a wildcard SSL certificate mean?
Technically a wildcard is an ordinary X.509 server certificate. The only difference is one entry in its Subject Alternative Name (SAN) extension: a DNS name whose leftmost label is a single asterisk. Browsers, curl, Java and Python match it using the rules in RFC 9525 (service identity in TLS): the asterisk stands for exactly one whole label, and only in the leftmost position.
So *.example.com matches:
www.example.comapi.example.comapp.example.commail.example.comtenant-4821.example.com— any name that did not exist when the certificate was issued
It does not match:
example.com— the bare domain is a different name. Commercial CAs usually add it as a second SAN for free; with Let's Encrypt you request it yourself.sub.api.example.com— two labels to the left of the base domain. You need*.api.example.comfor that level.example.org— a different domain.
Patterns such as *.*.example.com, api*.example.com or *.com are not issued by publicly trusted CAs, and wildcards cannot be issued for IP addresses. When a browser meets a name the certificate does not list, it shows the error described in ERR_CERT_COMMON_NAME_INVALID: certificate name mismatch.
Wildcard example: reading the SAN list
A typical wildcard certificate for a small company carries two names. You can see them on any live server with OpenSSL 1.1.1 or newer:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName -enddateOutput for a wildcard looks like this:
subject=CN = *.example.com
X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:example.com
notAfter=...Only the SAN list matters for hostname matching. The Common Name (CN) is legacy — modern browsers ignore it — so a certificate with CN=*.example.com but no matching SAN will fail in Chrome.
Wildcard certificate vs SSL certificate: what is the difference?
"Wildcard certificate vs SSL certificate" is a false contrast: a wildcard is an SSL/TLS certificate. The real choice is how many names one certificate covers and how you list them. The detailed trade-off is in Wildcard vs SAN certificate; in short:
| Type | Names covered | Covers new subdomains automatically | Typical use |
|---|---|---|---|
| Single-domain | One FQDN (often plus www) | No | A single site on one server |
| Wildcard | *.example.com, usually plus example.com | Yes, one level only | SaaS tenant subdomains, many environments behind one proxy |
| Multi-domain (SAN/UCC) | An explicit list of names, possibly across domains | No — reissue to add a name | A fixed set of hosts, several brands on one server |
| Multi-domain wildcard | Several wildcards, e.g. *.example.com and *.example.net | Yes, one level per listed wildcard | Groups of domains with dynamic subdomains |
Wildcard versus individual certificates, side by side:
| Aspect | Wildcard | Individual certificates |
|---|---|---|
| Coverage | All first-level subdomains | Only the names requested |
| Management | One certificate to renew and deploy | One per host (trivial with ACME automation) |
| Security risk | Higher — one stolen key impersonates every subdomain | Lower — compromise is isolated to that host |
| Revocation | Revoking hits every service using it at once | Revoke one host at a time |
| Hostname exposure in CT logs | Only *.example.com is published | Every hostname is published |
| Validation levels | DV or OV (EV wildcards are not allowed) | DV, OV or EV |
| Validation method | DNS record (Let's Encrypt), or DNS/email at commercial CAs | HTTP file, DNS or email |
For what DV, OV and EV actually verify, see SSL certificate types.
When a wildcard makes sense
- Dynamic subdomains. SaaS platforms where each customer gets
customer.app.example.com— you cannot request a certificate before the tenant exists, and per-tenant issuance at scale hits CA rate limits. - One TLS termination point. A reverse proxy, load balancer or CDN that fronts many subdomains holds the key in one place, which neutralizes most of the risk.
- Internal hostnames you don't want published. Every publicly trusted certificate is logged in Certificate Transparency; a wildcard reveals only the domain, not names like
vpn-admin.example.com. - Short-lived environments. Preview deployments such as
pr-512.staging.example.comcovered by*.staging.example.com.
When not to use one
- Subdomains on different servers or with different owners. Each server needs a copy of the same private key. A mail server, a marketing site run by an agency and a payment API should not share one.
- A handful of stable hostnames. With ACME automation, separate certificates cost nothing and isolate failures.
- EV requirement. The EV guidelines forbid wildcards.
- Multi-level names.
*.example.comwill never covereu.api.example.com; you would need an additional wildcard per level.
Security considerations
- Key distribution. Every copy of the private key is an exposure. Anyone holding it can present a valid certificate for any subdomain, including ones you have never used.
- Cross-service attacks. When a wildcard is shared between HTTPS and other TLS services (FTP, SMTP, IMAP), a weaker service can be used against the web one — the ALPACA class of attacks. The US NSA published guidance on wildcard risks and ALPACA for exactly this reason. Keep web and mail on separate certificates.
- Revocation blast radius. If the key leaks, you revoke once and every service using it must be reissued and redeployed at the same time. Rehearse that.
- Subdomain takeover is a DNS problem, not a certificate one. A dangling CNAME to a deleted cloud resource lets an attacker claim the name and get their own certificate from the provider; your wildcard neither causes nor prevents that. Audit DNS for records pointing at decommissioned services — see wildcard DNS records for the related pitfalls of wildcard records.
- Connection coalescing. With HTTP/2 and HTTP/3, a browser may reuse one connection for different subdomains when they resolve to the same IP and the certificate covers both. If those hosts are served by different virtual hosts, the server should answer
421 Misdirected Request; misconfigured setups instead serve the wrong site.
How can I create a wildcard SSL certificate?
There are two paths: free and automated through ACME, or bought from a CA or reseller with a CSR.
Wildcard SSL certificate with Let's Encrypt
Let's Encrypt has issued free wildcards since 2018, with one condition: validation must use the DNS-01 challenge. HTTP-01 cannot prove control of names that do not exist yet. You publish a TXT record at _acme-challenge.example.com; when you request both example.com and *.example.com, the same name holds two TXT values at once, which is expected.
With a DNS provider plugin (here Cloudflare), issuance and renewal are fully automatic:
certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d example.com -d '*.example.com'Quote '*.example.com': unquoted, the shell may try to expand the asterisk against files in the current directory. Certbot lists the available DNS plugins in its documentation. The same with acme.sh and the Cloudflare API:
acme.sh --issue --dns dns_cf -d example.com -d '*.example.com'Without an API-capable DNS host you can use certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com', but manual certificates do not renew on their own — fine for a test, wrong for production. Before letting the CA validate, confirm the TXT record is visible from outside:
dig +short TXT _acme-challenge.example.com @1.1.1.1Step-by-step certbot setup is in free SSL via Let's Encrypt; if renewals start failing, work through Certbot not renewing.
Buying a wildcard (GoDaddy, Sectigo, DigiCert and other CAs)
Generate the key and CSR on the server that will use them, so the private key never travels:
openssl req -new -newkey rsa:2048 -nodes \
-keyout wildcard.example.com.key -out wildcard.example.com.csr \
-subj "/CN=*.example.com" \
-addext "subjectAltName=DNS:*.example.com,DNS:example.com"Paste the CSR into the vendor's order form, pass domain validation (usually a DNS TXT/CNAME record or an email to an address such as admin@example.com; OV adds organization checks), then install the issued certificate together with its intermediate chain. A missing intermediate is the most common post-install failure — see incomplete certificate chain.
Allow wildcard issuance in CAA
If your domain has CAA records, a wildcard is governed by the issuewild tag when one is present, and by issue otherwise (RFC 8659). An issuewild ";" record forbids wildcards from every CA, so a leftover one makes every wildcard order fail. To allow Let's Encrypt for both kinds:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"More on the syntax in CAA DNS record.
Install it in nginx
server {
listen 443 ssl;
http2 on;
server_name example.com *.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}Certbot names the directory after the first -d value, hence live/example.com. Point ssl_certificate at fullchain.pem, not cert.pem, or clients will miss the intermediate. On nginx older than 1.25.1, use listen 443 ssl http2; instead of the separate http2 on; directive. In Apache the equivalents are SSLCertificateFile (full chain) and SSLCertificateKeyFile, with ServerAlias *.example.com.
How much does a wildcard SSL certificate cost?
A wildcard SSL certificate can be free. Let's Encrypt, ZeroSSL and Google Trust Services issue DV wildcards through ACME at no charge; Cloudflare's Universal SSL covers the apex and first-level subdomains for proxied hostnames; AWS Certificate Manager issues wildcards free for use with its own load balancers and CloudFront.
Paid wildcards are priced by the CA and, far more widely, by resellers — the same Sectigo DV wildcard is sold at different prices on different storefronts, so compare the exact product name rather than the brand of the shop. What the higher price buys:
- OV validation — your organization name in the certificate, which some procurement or compliance policies require;
- vendor support and a warranty — the warranty covers the relying party under specific conditions and rarely matters in practice;
- multi-year subscriptions — you pay for several years, but each issued certificate is still limited to the maximum validity and must be reissued and reinstalled within the term.
Encryption strength is identical for free and paid wildcards: the key algorithm and cipher suites are chosen by you and your server, not by the price.
Are wildcard certs going away?
No. Neither browsers nor the CA/Browser Forum have banned wildcards, and all major CAs still issue them. What is changing is lifetime. Under CA/Browser Forum ballot SC-081, the maximum validity of publicly trusted TLS certificates drops to 200 days from March 15, 2026, to 100 days from March 15, 2027, and to 47 days from March 15, 2029, with domain-validation reuse periods shrinking alongside.
For wildcards this has a practical consequence: manual DNS validation and hand-copied key files stop being workable. If a wildcard is still renewed by someone logging into the DNS panel once a year, move it to an API-driven DNS-01 setup now, and keep the number of servers holding the key small enough that redeploying every few weeks is a script, not a project.
Configuration checklist
- Include the bare domain as a second SAN:
example.complus*.example.com. - Automate renewal with DNS-01 through your DNS provider's API; use a DNS API token scoped to the one zone.
- Terminate TLS in as few places as possible — a reverse proxy or load balancer, so only it holds the private key.
- Separate high-value services (payments, admin panels, mail) onto their own certificates.
- Watch Certificate Transparency for certificates you did not order — how CT monitoring works.
- Have a rotation runbook: revoke, reissue with a new key, redeploy everywhere, verify.
How to check a wildcard certificate
Run a few subdomains, including the bare domain, through the enterno.io SSL checker: it shows the SAN list, issuer, chain and days until expiry, so you can confirm that *.example.com actually covers the host you typed and that the intermediate is served. Before issuance, use the DNS lookup to verify the _acme-challenge TXT and CAA records. Since one wildcard often protects dozens of hostnames, one missed renewal takes all of them down at once — add the key subdomains to uptime and SSL monitoring to get an alert before the expiry date.
FAQ
Does a wildcard certificate cover the root domain?
Not by itself. *.example.com does not match example.com. Most paid wildcards include the root as a second SAN; with Let's Encrypt add -d example.com to the request.
Does *.example.com cover sub.api.example.com?
No. The asterisk replaces exactly one label. Add *.api.example.com as another SAN or issue a separate certificate for that level.
Can I get a free wildcard SSL certificate?
Yes. Let's Encrypt, ZeroSSL and Google Trust Services issue free DV wildcards via ACME with DNS-01 validation. They are trusted by the same browsers as paid DV certificates.
Why does Let's Encrypt need a DNS record for a wildcard?
A wildcard covers names that may not exist, so the CA cannot fetch a file from each of them. Only control of the zone itself, proven with a TXT record at _acme-challenge, demonstrates authority over every subdomain.
Is a wildcard certificate less secure?
The encryption is the same. The risk is operational: one private key protects every subdomain, so the more servers hold it, the bigger the damage from a single leak.
Can I get an EV wildcard certificate?
No. The EV guidelines do not permit wildcard names. Use OV for a wildcard, or separate EV certificates for specific hostnames.
