A wildcard SSL certificate secures a domain and all of its direct subdomains under a single certificate using a *.example.com pattern. One certificate covers www.example.com, api.example.com, mail.example.com, and every other direct subdomain — including ones you add later. It does not cover the root domain (example.com) unless listed separately as a SAN, and it does not cover second-level subdomains like sub.sub.example.com.
When a wildcard makes sense
If you run — or plan to run — multiple subdomains under one domain (www, api, mail, blog, shop, staging…), a wildcard saves money and management overhead versus separate certificates for each. If you only have one or two subdomains with no growth plans, individual DV or OV single-domain certificates may cost less overall.
What a wildcard SSL certificate covers
The asterisk (*) matches any single label in a domain name. So *.example.com matches exactly one subdomain level:
| Domain | Covered by *.example.com? |
|---|---|
| www.example.com | Yes |
| api.example.com | Yes |
| mail.example.com | Yes |
| shop.example.com | Yes |
| staging.example.com | Yes |
| example.com (root) | No — Needs a separate SAN |
| sub.sub.example.com | No — Two levels deep |
| another-domain.com | No — Different root domain |
The coverage is unlimited within that one subdomain level. Add as many direct subdomains as your infrastructure requires — the certificate covers them without reissuance.
What a wildcard doesn't cover
The root domain
*.example.com does not cover example.com itself. Most CAs include the root as a SAN automatically — confirm before purchase.
Second-level subdomains
*.example.com does not match sub.sub.example.com. If your architecture uses nested subdomains, you need a separate certificate for that level, or a multi-domain SAN that lists each one explicitly.
Other root domains
*.example.com does not cover another-site.com or its subdomains. For multi-root coverage, a multi-domain (SAN) or wildcard SAN certificate is needed.
DV wildcard vs OV wildcard
Wildcard certificates come in DV and OV flavors. The wildcard scope is identical — both cover *.yourdomain.com. The difference is what the CA verifies about you before issuing.
DV Wildcard | OV Wildcard | |
|---|---|---|
| Validation | Domain control only | Organization existence + domain control |
| Issuance time | Minutes | 1–3 business days |
| Typical price | ~$50–$200/yr | ~$200–$600/yr |
| Organization in certificate | No | Yes |
| Encryption strength | Identical to OV | Identical to DV |
| Best for | Dev, staging, internal services, simple public subdomains | Customer-facing apps, ecommerce, SaaS, banking portals |
Price ranges are indicative for 2026 and vary by CA. Browse DV SSL options, OV SSL options, or full SSL pricing.
Why EV wildcard certificates don't exist
Extended Validation certificates cannot use wildcards. The CA/Browser Forum's EV Guidelines explicitly prohibit wildcard characters in EV certificates. The reason is intrinsic to what EV means: every domain listed in an EV certificate must be individually vetted with strict, standardized checks. A wildcard pattern represents an unbounded set of subdomains — it is impossible to individually vet something undefined.
If you need EV-level vetting across multiple subdomains, use an EV multi-domain (SAN) certificate and list each subdomain explicitly. For a comparison of OV and EV validation depth, see our OV vs EV SSL guide.
Wildcard vs multi-domain (SAN) certificates
These are the two main patterns for covering more than one hostname on a certificate. Understanding the tradeoffs helps you avoid over- or under-buying.
Wildcard
- Unlimited subdomains at one level
- Add new subdomains without reissuing
- One certificate to manage and deploy
- One root domain only
- Not available for EV
- Does not cover deeper subdomain levels
Multi-domain (SAN)
- Multiple different root domains on one cert
- Available for DV, OV, and EV
- Cover specific deep subdomains
- Fixed SAN list — adding a domain requires reissue
- Each SAN individually validated (especially for OV/EV)
Can you combine them? Yes — a wildcard SAN certificate lists *.example.com alongside other SANs like another-domain.com on the same certificate. This is the most flexible option for organizations with multiple root domains and many subdomains, though it's also the most expensive.
For a full breakdown of how SAN certificates work, see our multi-domain SSL certificate guide.
Wildcard SSL and the 199-day validity limit
Since March 2026, all publicly-trusted SSL/TLS certificates — including wildcards — are capped at 199 days' validity under CA/Browser Forum Ballot SC-081v3. For wildcard certificates, this creates a specific operational risk.
A single wildcard typically protects dozens of services simultaneously. When it expires, every subdomain using it fails at once. The margin for a missed renewal is zero — making wildcards one of the highest-impact certificates to manage manually, and amplifying the case for automation.
Validity schedule (all public TLS certs)
- • March 2026: max 199 days (active now)
- • March 2027: max 100 days
- • March 2029: max 47 days
Full breakdown: SSL Certificates Are Now Limited to 199 Days.
Automating wildcard certificate renewal
ACME (RFC 8555) automates wildcard issuance and renewal. The catch: wildcards require the DNS-01 challenge, not HTTP-01. To pass DNS-01, your ACME client must write a TXT record to your domain's DNS zone during validation — which means you need a DNS provider with an API and credentials scoped to TXT record writes.
What you need for DNS-01 automation
- A DNS provider with an API (Cloudflare, Route 53, Google Cloud DNS, etc.)
- An ACME client with a DNS plugin — Certbot, acme.sh, or Caddy
- API credentials scoped to TXT record writes only (limit blast radius)
- A cron job or systemd timer triggering renewal at ~80% of the validity period
If you can't automate yet
Set a calendar reminder to start the renewal process 30 days before expiry, and independently monitor your certificate's expiration date. With 47-day certificates arriving in 2029, manual management of wildcards will become impractical — planning DNS-01 automation now is a better investment than revisiting it every six weeks.