Wildcard TLS Certificates: Convenience vs Security Trade-offs

What is a wildcard certificate?

A wildcard certificate is a TLS/SSL certificate that covers a domain and all of its first-level subdomains using an asterisk (*) as a placeholder. For example, a certificate issued for *.yourcompany.com is valid for:

• www.yourcompany.com
• api.yourcompany.com
• staging.yourcompany.com
• anything-else.yourcompany.com

It does not cover:

• yourcompany.com itself (the bare domain) -- unless explicitly included as a Subject Alternative Name (SAN)
• Multi-level subdomains like dev.api.yourcompany.com

Why organisations use wildcards

The appeal is obvious:

• Convenience -- one certificate covers dozens or hundreds of subdomains without managing individual certificates for each
• Cost savings -- one purchase instead of many (less relevant with free Let's Encrypt certificates, but still a factor for OV/EV certificates)
• Simpler renewal -- renew one certificate instead of tracking dozens of expiry dates
• Faster deployment -- spin up a new subdomain and HTTPS works immediately without requesting a new certificate

For these reasons, wildcards are extremely common. But they come with real security trade-offs that many teams overlook.

Security risks of wildcard certificates

Compromise of one server exposes all subdomains

This is the fundamental problem. A wildcard certificate uses the same private key across every server that uses it. If an attacker compromises any one of those servers and extracts the private key, they can:

• Impersonate any subdomain covered by the wildcard
• Perform man-in-the-middle attacks on any subdomain's traffic
• Decrypt captured traffic (if the cipher suite does not provide forward secrecy)

With individual certificates, compromising one server only compromises that one subdomain.

Private key distribution challenges

To use a wildcard certificate on multiple servers, the private key must be copied to each one. Every copy is another potential leak vector. Consider:

• The key lives on your web servers, API servers, staging servers, and possibly CDN nodes
• Each server has different security postures -- your staging server is probably less hardened than production
• Employees with access to any of these servers have access to the key
• Backups of any of these servers contain the key

Revoking a wildcard is painful

If the private key is compromised and you revoke the wildcard certificate, every service using it goes down simultaneously until you deploy a new certificate to all servers. With individual certificates, you revoke and replace just the affected one.

Certificate transparency reveals your wildcard

All publicly trusted certificates are logged in Certificate Transparency (CT) logs. A wildcard certificate for *.yourcompany.com tells attackers that subdomains exist and are worth enumerating. While CT logs reveal individual certificates too, a wildcard signals a potentially large attack surface.

Wildcards can mask shadow IT

Because *.yourcompany.com covers everything, new subdomains get valid HTTPS automatically. This removes a natural checkpoint -- with individual certificates, someone has to request a certificate for a new subdomain, which creates visibility. Wildcards let subdomains appear silently.

When wildcards are appropriate

Wildcards are not inherently bad. They make sense when:

• All subdomains are on the same infrastructure -- if everything runs on the same cluster or CDN, the private key is already in one place
• You use a CDN or load balancer -- the wildcard lives on the CDN edge (Cloudflare, AWS CloudFront, etc.) and the private key is managed by the provider
• You have strong key management -- HSMs, secret management tools (HashiCorp Vault, AWS Secrets Manager), and automated rotation
• The domain is low risk -- internal or development domains where the impact of compromise is limited

When to use individual certificates instead

Use per-subdomain certificates when:

• Subdomains are on different servers or networks -- each server should have its own certificate and key
• High-value services -- payments.yourcompany.com or admin.yourcompany.com deserve their own certificates with independent key management
• You use Let's Encrypt -- automated issuance and renewal makes managing many certificates nearly free
• You want to limit blast radius -- compromising one certificate should not affect others
• Different teams manage different subdomains -- sharing a wildcard key across teams creates unnecessary cross-team trust

Best practices for wildcard certificates

If you do use wildcards, follow these guidelines:

Limit the scope

Do not use a wildcard for your top-level domain if you can avoid it. Consider wildcards for specific purposes:

• *.cdn.yourcompany.com for CDN assets
• *.internal.yourcompany.com for internal services

This limits the damage if the key is compromised.

Use short-lived certificates

The shorter the certificate lifetime, the smaller the window for exploitation. Let's Encrypt certificates are valid for 90 days and can be renewed automatically. Some organisations use even shorter lifetimes (days or hours) with automated issuance.

Store private keys securely

• Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
• Never store private keys in source code repositories
• Restrict file system permissions on key files (chmod 600, owned by root)
• Consider HSMs for high-value wildcard certificates

Monitor Certificate Transparency logs

Use CT log monitoring to detect unexpected certificates issued for your domain. If someone compromises your wildcard key and uses it, or if a rogue certificate is issued, CT monitoring is your early warning system. See our guide on certificate transparency monitoring.

Automate renewal

An expired wildcard certificate takes down every service using it simultaneously. Automate renewal with certbot or your CA's API and monitor expiry dates.

Rotate keys on renewal

Do not reuse the same private key across certificate renewals. Generate a new key pair each time you renew.

How to check your wildcard certificates

View certificate details with openssl

# Check what names a certificate covers
openssl s_client -connect yourcompany.com:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Check on SSL Labs

Visit SSL Labs Server Test and look at the "Subject" and "Subject Alternative Names" fields to see if a wildcard is in use.

Search Certificate Transparency logs

Visit crt.sh and search for %.yourcompany.com to see all certificates -- including wildcards -- that have been issued for your domain.

For a broader look at TLS health, see our guides on expired TLS certificates and weak TLS cipher suites.

How SurfaceScan helps

SurfaceScan detects wildcard certificates across your attack surface and flags the associated risks. It identifies which subdomains share the same wildcard certificate, checks for impending expiry, and monitors Certificate Transparency logs for unexpected issuances. Findings appear in the TLS Certificates section, so you can see at a glance where wildcards are in use and whether their coverage matches your expectations.