Wildcard SSL Certificates: Setup, Limitations, and Best Practices

What a Wildcard SSL Certificate Actually Covers

A wildcard SSL certificate secures a domain and all of its single-level subdomains using the *. prefix in the Common Name (CN) or Subject Alternative Name (SAN) field. The asterisk matches exactly one DNS label — no more, no less.

What a wildcard for *.example.com covers:

• www.example.com ✓
• api.example.com ✓
• mail.example.com ✓
• blog.example.com ✓
• anything.example.com ✓

What it does NOT cover:

• example.com (the bare domain — unless explicitly included as a SAN)
• dev.api.example.com (multi-level subdomain — wildcards match only one label)
• staging.internal.example.com (three levels deep)
• otherdomain.com (entirely different domain — use a multi-domain/SAN certificate)

This single-label limitation is the most common misunderstanding about wildcard certificates. If you need dev.api.example.com covered, you need either a separate certificate for that specific name or a multi-level wildcard — which most public CAs will not issue. You can decode any certificate's coverage instantly with the SSL Certificate Decoder to see exactly which SANs are included and which wildcard patterns are active.

Setting Up a Wildcard Certificate

The certificate request process is identical to a standard certificate except for the domain name. The difference is in validation — and wildcard validation is where most people trip.

Step 1: Generate the CSR with the wildcard domain

# Generate private key and CSR in one step
openssl req -new -newkey rsa:2048 -nodes \
  -keyout wildcard.example.com.key \
  -out wildcard.example.com.csr \
  -subj "/CN=*.example.com"

# Add SANs for the bare domain and wildcard
cat > san.conf <<EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.example.com
DNS.2 = example.com
EOF

openssl req -new -newkey rsa:2048 -nodes \
  -keyout wildcard.example.com.key \
  -out wildcard.example.com.csr \
  -config san.conf \
  -subj "/CN=*.example.com"

Step 2: Domain validation — the wildcard hurdle

Most Certificate Authorities require DNS-01 validation for wildcard certificates. HTTP-01 validation (placing a file on your web server) typically does not work because the CA must prove you control the entire domain, not just a single subdomain. DNS-01 validation requires creating a TXT record at the domain apex — something only the domain owner can do.

For Let's Encrypt with Certbot, add the --preferred-challenges dns flag and configure a DNS plugin for your provider (Cloudflare, Route53, DigitalOcean, etc.). Manual DNS validation is possible but impractical for automated renewal — you need the plugin for unattended operation.

Step 3: Verify the certificate after issuance

Before deploying, decode the certificate to confirm the wildcard pattern and all SANs are present. Use the SSL Certificate Decoder or OpenSSL:

# View all SANs in the certificate
openssl x509 -in wildcard.example.com.crt -text -noout | grep -A1 "Subject Alternative"

# Verify the certificate chain is complete
openssl verify -CAfile chain.pem wildcard.example.com.crt

The Security Tradeoff: One Key to Rule Them All

The convenience of a wildcard certificate comes with a hard security reality: one compromised private key exposes every subdomain that certificate covers.

Real-world blast radius comparison:

• Per-subdomain certificates: compromise of api.example.com's key exposes only that subdomain. Other services remain secure. Revocation of one certificate doesn't affect others.
• Wildcard certificate: compromise of the wildcard private key (deployed on api.example.com, mail.example.com, dashboard.example.com, and 25 other subdomains) exposes all of them simultaneously. Revocation breaks everything at once.

Where the private key lives matters. If your wildcard key is on a CDN edge node, a load balancer, a Kubernetes ingress controller, and a dozen application servers, your attack surface is the union of every server that touches that key. An attacker who compromises the least-secured server in that set owns every subdomain.

Mitigation strategies: Use wildcards only where the operational benefit outweighs the risk. For high-value subdomains (admin panels, payment APIs, customer data services), issue separate certificates with their own keys. For low-risk, high-volume subdomains (CDN edge nodes, static content, development environments), a wildcard may be acceptable — but never share the key with the high-value services.

Renewal Complications: Why Wildcards Make Automation Harder

Renewing a wildcard certificate means updating every server, application, and service that uses it — simultaneously. If even one service misses the update, that service starts serving an expired certificate while everything else works fine. These partial failures are hard to detect because monitoring often checks only the primary domain.

Alternatives to Wildcard Certificates

Multi-Domain SAN Certificate

A single certificate that lists up to 100+ specific domain names in the Subject Alternative Name extension. Each name is explicit — no wildcards. You get one certificate, one key, one renewal, but you control exactly which names are covered. Better for moderate numbers of known subdomains. The SSL Decoder shows the full SAN list for any certificate.

Per-Subdomain Certificates

One certificate per subdomain with its own private key. Maximum isolation — compromise of one key exposes only one service. Higher operational overhead but dramatically better security posture. Let's Encrypt and the ACME protocol make this practical at scale: automated issuance per host with no per-certificate cost.

Recommendation: Start with per-subdomain certificates and automated ACME issuance. Move to a wildcard only when you have a concrete operational problem that per-subdomain certs can't solve (e.g., you deploy to thousands of ephemeral subdomains that can't each complete DNS validation). The default should be isolation, not convenience.

Related SSL Tools

• SSL Certificate Checker — Verify certificate validity, expiry date, chain trust, protocol support, and cipher suites for any HTTPS endpoint. Get warnings for expiring certificates before they break.
• SSL Certificate Decoder — Decode any X.509 certificate (PEM, DER) to inspect the full details — SAN list, issuer, validity window, key size, signature algorithm, extensions, and wildcard patterns.

Frequently Asked Questions