Wildcard Certificates: What They Cover and What They Don't

What Is a Wildcard Certificate?

A wildcard certificate secures a domain and all its single-level subdomains using an asterisk (*) in the Common Name or SAN field:

*.example.com

This one certificate covers: - www.example.com - mail.example.com - api.example.com - anything.example.com

What Wildcards Don't Cover

The bare domain

*.example.com does not cover example.com (no subdomain). You need to include both in the certificate:

SAN: *.example.com, example.com

When you generate a certificate at getaCert.com, add both as SAN entries.

Multi-level subdomains

*.example.com does not cover sub.sub.example.com. The wildcard only matches one level:

For deeper subdomains, you need a separate wildcard (*.api.example.com) or list them explicitly as SANs.

Other domains

*.example.com doesn't cover *.example.org or *.otherdomain.com. Each domain needs its own certificate (or use a multi-domain SAN certificate).

Wildcard vs SAN Certificates

Wildcard: One certificate for *.example.com -- unlimited subdomains at one level.

SAN (Subject Alternative Name): One certificate listing specific hostnames:

SAN: example.com, www.example.com, api.example.com, mail.example.com

Best practice: Use SAN certificates when you know all your hostnames. Use wildcards when subdomains are dynamic or numerous.

Getting a Wildcard Certificate

Let's Encrypt (free)

Let's Encrypt issues wildcard certificates but requires DNS-01 validation -- you must create a TXT record in your DNS. HTTP validation doesn't work for wildcards.

certbot certonly --manual --preferred-challenges dns \
    -d "*.example.com" -d "example.com"

You can also use our Let's Encrypt proxy for DNS-01 validation.

Self-signed wildcard (for development)

Generate one instantly at getaCert.com:

1. Enter *.example.com as the Common Name
2. Add example.com as a SAN (to cover the bare domain too)
3. Download your certificate

Or with OpenSSL:

openssl req -x509 -newkey rsa:2048 -nodes \
    -keyout wildcard.key -out wildcard.pem \
    -days 365 -subj "/CN=*.example.com" \
    -addext "subjectAltName=DNS:*.example.com,DNS:example.com"

Commercial providers

Most commercial CAs offer wildcard certificates at a premium over single-domain certs. See our provider comparison for pricing.

Security Considerations

Key compromise affects all subdomains

If an attacker steals the private key for *.example.com, they can impersonate every subdomain. With individual certificates, compromising one key only affects one hostname.

Mitigation: Limit who has access to the wildcard certificate's private key. Don't deploy it to every server -- use a reverse proxy that terminates TLS.

Wildcard certificates and certificate transparency

Every publicly trusted certificate is logged in Certificate Transparency (CT) logs. Wildcard certificates don't reveal your subdomain names in CT logs (only *.example.com appears), which can be a privacy advantage over SAN certificates that list every hostname.

Revocation scope

If you need to revoke a wildcard certificate, all subdomains lose their certificate simultaneously. With individual certs, you revoke only the compromised one.

Common Mistakes

Forgetting the bare domain

Always include both *.example.com AND example.com in your certificate. Users will visit both.

Assuming multi-level coverage

*.example.com won't work for staging.api.example.com. You need *.api.example.com or a SAN entry for that specific hostname.

Using wildcards in internal environments

For internal services with known hostnames, SAN certificates are more secure and easier to manage. Save wildcards for when you truly have dynamic subdomains.

Next Steps

• Generate a wildcard certificate for development
• Learn about certificate types (DV, OV, EV)
• Read about SAN support in getaCert.com certificates