What Is a Wildcard Certificate? When to Use It (And When Not To)

A wildcard certificate is a TLS certificate that secures a domain and all its single-level subdomains using a wildcard character (*) in the Subject Alternative Name. A certificate for *.example.com is valid for www.example.com, api.example.com, mail.example.com, and any other subdomain — but NOT for example.com itself (the bare domain) or multi-level subdomains like dev.api.example.com.

Wildcards reduce certificate management overhead (one cert instead of dozens), but they concentrate risk (one compromised key exposes every subdomain). Understanding this trade-off is essential for making the right architectural decision.

---

How Wildcard Certificates Work

What They Match

Certificate SAN: *.example.com

✅ Matches:
  www.example.com
  api.example.com
  mail.example.com
  staging.example.com
  anything.example.com

❌ Does NOT match:
  example.com          (bare domain — need separate SAN entry)
  dev.api.example.com  (multi-level — wildcard only covers ONE level)
  sub.sub.example.com  (multi-level)

Common Configuration (Wildcard + Bare Domain)

Most wildcard certificates include both the wildcard and the bare domain:

Subject Alternative Names:
  DNS: *.example.com
  DNS: example.com

This covers both www.example.com (via wildcard) and example.com (via explicit SAN).

Issuance Requirements

• DV wildcard: Prove control of the base domain (DNS-01 challenge required for Let’s Encrypt)
• OV/EV wildcard: Organization validation + domain control
• DNS-01 is mandatory for Let’s Encrypt wildcards (HTTP-01 can’t prove wildcard control)

# Let's Encrypt wildcard (requires DNS-01)
certbot certonly --dns-cloudflare \
  -d "example.com" \
  -d "*.example.com" \
  --dns-cloudflare-credentials /etc/cloudflare.ini

---

When to Use Wildcard Certificates

Good Use Cases

1. Many subdomains on the same infrastructure:

One load balancer serves:
  www.example.com
  app.example.com
  api.example.com
  docs.example.com
  status.example.com

→ One wildcard cert on the LB instead of 5 individual certs
→ Simpler configuration, one renewal to manage

2. Dynamic subdomains (multi-tenant SaaS):

Each customer gets: customer-name.yourapp.com
New customers added daily
Can't pre-provision individual certs for unknown future subdomains

→ Wildcard covers all current and future customer subdomains

3. Development/staging environments:

dev.example.com
staging.example.com
test.example.com
preview-123.example.com

→ One wildcard for all non-production subdomains
→ Less management overhead for environments that change frequently

Bad Use Cases (Don’t Use Wildcards Here)

1. Different security zones:

public-website.example.com  (public, low sensitivity)
admin-panel.example.com     (internal, high sensitivity)
payment-api.example.com     (PCI scope, highest sensitivity)

→ DON'T share one wildcard across different security zones
→ If the key is compromised on the public website, the payment API is also compromised
→ Use individual certificates with separate keys per security zone

2. Different teams/ownership:

marketing.example.com  (marketing team manages)
api.example.com        (engineering team manages)
hr.example.com         (HR vendor manages)

→ Sharing a wildcard means sharing the private key across teams
→ Any team's compromise affects all teams
→ Use individual certs with separate ownership

3. Compliance-scoped environments:

If payment-api.example.com is in PCI scope:
→ A wildcard shared with non-PCI systems brings those systems INTO scope
→ The private key handling must meet PCI requirements everywhere it's deployed
→ Use a dedicated certificate for PCI-scoped services

---

Security Trade-Offs

The Shared Key Problem

A wildcard certificate has ONE private key. That key must be deployed to every server that uses the certificate. If you have 20 servers using *.example.com:

20 servers × 1 shared private key = 20 potential compromise points

If ANY of the 20 servers is compromised:
→ Attacker has the private key
→ Attacker can impersonate ANY subdomain (www, api, admin, payment...)
→ Attacker can perform MITM on any subdomain's traffic
→ ALL 20 servers must be considered compromised
→ Certificate must be revoked (affecting all 20 servers simultaneously)

With individual certificates:

20 servers × 20 separate keys = compromise of 1 server affects only 1 service

The Blast Radius

Scenario	Wildcard Impact	Individual Cert Impact
One server compromised	All subdomains at risk	Only that service at risk
Key needs rotation	All 20 servers updated simultaneously	Only 1 server updated
Certificate revoked	All 20 services go down	Only 1 service affected
Audit scope	All servers sharing the key are in scope	Only the specific server

Certificate Transparency Exposure

Wildcard certificates appear in CT logs as *.example.com. This doesn’t reveal specific subdomains — actually providing LESS reconnaissance information than individual certificates (which reveal each subdomain name).

---

Cost Comparison

Approach	Let’s Encrypt	DigiCert	Sectigo
1 wildcard cert	Free	$500-800/year	$80-200/year
20 individual DV certs	Free	$4,000-8,000/year	$160-1,000/year
Management overhead	1 renewal vs 20	1 renewal vs 20	1 renewal vs 20

With Let’s Encrypt (free), cost isn’t a factor. The decision is purely about security and operations. With paid CAs, wildcards save significant money.

---

Wildcard Certificate Limitations

1. Single Level Only

*.example.com covers:  sub.example.com
Does NOT cover:        sub.sub.example.com

Need multi-level? Options:
  a) Separate wildcard: *.api.example.com (covers dev.api.example.com)
  b) Individual SAN entries for each multi-level subdomain
  c) Restructure to avoid multi-level subdomains

2. No IP Address Wildcards

Wildcards only work with DNS names. You can’t have a wildcard for IP addresses.

3. Some Services Don’t Support Wildcards

Certain services or protocols may not accept wildcard certificates (rare, but check your specific use case).

4. Revocation Affects Everything

If you need to revoke a wildcard certificate (key compromise), every service using it loses its certificate simultaneously. You must have a new certificate ready to deploy to all servers before revoking.

---

Best Practices

1. Limit Wildcard Scope

Instead of: *.example.com (covers everything)
Consider:   *.app.example.com (covers only application subdomains)
            *.internal.example.com (covers only internal services)
            Individual certs for high-security services

2. Don’t Deploy the Same Wildcard Everywhere

❌ Same *.example.com cert on: web servers, API servers, mail servers, dev servers

✅ Separate wildcards per zone:
   *.example.com → public web (CDN/LB)
   *.internal.example.com → internal services (private CA, not even wildcard)
   Individual certs → payment, admin, compliance-scoped services

3. Store the Private Key Securely

Since the wildcard key protects ALL subdomains, it’s higher value than an individual cert key:

• Store in HSM or KMS (not plaintext on disk)
• Restrict access (fewer people/systems than individual certs)
• Monitor for unauthorized access
• Rotate more frequently (the blast radius justifies the effort)

4. Automate Renewal

# Let's Encrypt wildcard with DNS-01 (automated)
acme.sh --issue -d "example.com" -d "*.example.com" --dns dns_cf
acme.sh --install-cert -d example.com \
  --key-file /etc/ssl/private/wildcard.key \
  --fullchain-file /etc/ssl/certs/wildcard.pem \
  --reloadcmd "systemctl reload nginx"

---

FAQ

Q: Can I get a free wildcard certificate? A: Yes — Let’s Encrypt issues free wildcard certificates. Requires DNS-01 challenge (you must have API access to your DNS provider for automation).

Q: Does a wildcard certificate cover the bare domain (example.com)? A: No — *.example.com does NOT match example.com. You need both SANs: *.example.com AND example.com. Most CAs include both when you request a wildcard.

Q: Can I have multiple wildcards in one certificate? A: Yes — a SAN certificate can include multiple wildcards: *.example.com, *.example.org, *.app.example.com. Each is a separate SAN entry.

Q: Are wildcard certificates less secure? A: The encryption strength is identical. The security concern is operational: one shared private key across many services creates a larger blast radius if compromised. The certificate itself isn’t weaker — the deployment model is riskier.

Q: Should I use a wildcard or individual certs with cert-manager? A: With cert-manager, individual certificates are trivially easy to manage (one YAML per service, auto-renewed). The management overhead argument for wildcards disappears. Use individual certs in Kubernetes — they’re free, automated, and provide better isolation.

Q: Do wildcard certificates work with HTTP/2 and HTTP/3? A: Yes — wildcards work with all HTTP versions. The TLS layer (where the certificate is validated) is independent of the HTTP version.