Wildcard Certificates

A wildcard certificate lets you secure *.example.com instead of obtaining separate certificates for www.example.com, mail.example.com, and api.example.com. One certificate, one private key, unlimited first-level subdomains.

This is a trade-off. You're betting that protecting one private key well is easier than managing many certificates. Sometimes that bet makes sense. Sometimes it doesn't.

What the Asterisk Actually Matches

The asterisk in *.example.com matches any single string in that position. It covers www.example.com, mail.example.com, api.example.com, and even random-test-server-47.example.com.

But wildcards have two gaps that catch people:

The base domain isn't covered. *.example.com does not cover example.com itself. The asterisk represents a subdomain—it needs something to match. If you want both the wildcard and the base domain, your certificate must explicitly include both *.example.com and example.com in its Subject Alternative Names.

Deeper subdomains aren't covered. *.example.com does not cover api.staging.example.com or www.blog.example.com. The wildcard matches exactly one level. To cover subdomains under staging.example.com, you'd need a separate *.staging.example.com certificate.

The Security Trade-Off

Here's the bet you're making with a wildcard certificate:

With individual certificates, compromise of one private key affects one subdomain. Your blog gets breached? Your payment system is still protected by its own key.

With a wildcard, one private key protects everything. Compromise that key, and an attacker can impersonate any subdomain—your blog, your API, your admin panel, services you haven't even launched yet.

This isn't hypothetical risk. It's the reason high-security environments avoid wildcards. The convenience of one certificate isn't worth the blast radius of one compromised key.

When Wildcards Make Sense

Development and testing environments. You're spinning up test-branch-42.dev.example.com constantly. Nobody wants to request a new certificate for each ephemeral subdomain. The security stakes are lower, and the flexibility is worth it.

Small deployments under unified control. If you have five subdomains, they're all part of the same application, and you trust your private key storage, a wildcard simplifies your life without meaningful security cost.

Commercial certificate economics. When you're paying per certificate, a wildcard covering ten subdomains costs less than ten individual certificates. (This math changes with Let's Encrypt.)

When Wildcards Don't Make Sense

Different risk profiles on different subdomains. Your public marketing site and your administrative dashboard shouldn't share a private key. Compromise of one shouldn't risk the other.

Let's Encrypt users. Certificates are free and unlimited. The economic argument for wildcards evaporates. Individual certificates with automated renewal give you better isolation with minimal extra work.

Large organizations. When different teams manage different subdomains with different security requirements, a shared wildcard creates awkward dependencies and concentrated risk.

Wildcards and Let's Encrypt

Let's Encrypt issues wildcard certificates, but there's a catch: they require DNS validation. You can't use the simpler HTTP validation because the CA can't check subdomains that don't exist yet.

DNS validation means your renewal automation needs API access to your DNS provider. This adds complexity and a dependency. If your DNS API credentials are compromised, an attacker could potentially validate a certificate for your domain.

For Let's Encrypt users, the question is whether that added complexity is worth it. Often it isn't. Getting individual certificates for the subdomains you actually use is simpler and more secure.

SAN Certificates: The Middle Ground

Subject Alternative Name certificates let you list specific domains: example.com, www.example.com, api.example.com, mail.example.com—explicitly named, no wildcards.

You get the convenience of one certificate covering multiple domains without the "matches anything" exposure of a wildcard. Adding a new subdomain means getting a new certificate, but with automated issuance, that's seconds of work.

Let's Encrypt allows up to 100 names per certificate. For most deployments, a SAN certificate listing your actual subdomains beats a wildcard.

Private Key Security

Because a wildcard's private key protects multiple services, its security matters more than usual:

• Store it with restrictive permissions
• Consider hardware security modules for high-value deployments
• Monitor access to the key file
• Rotate certificates regularly
• Have an incident response plan

If you suspect the key is compromised, you must revoke and replace the certificate. Every subdomain goes down until you do. That's the concentrated risk of wildcards made tangible.

Multi-Level Wildcards Don't Exist

You can't use ..example.com to cover all subdomain depths. The asterisk must be the entire leftmost label, and you only get one.

To cover multiple levels, you need multiple wildcards: *.example.com plus *.staging.example.com plus *.api.example.com. At that point, you're managing multiple certificates anyway, and the wildcard benefit diminishes.

Certificate Transparency

Wildcard certificates appear in public Certificate Transparency logs. The pattern *.example.com is visible to anyone, announcing that you use subdomains even if you haven't disclosed which ones.

This usually doesn't matter, but if subdomain discovery is a concern—if you don't want people knowing internal.example.com exists—wildcards broadcast that information.

The Decision Framework

Ask yourself:

How many subdomains do I have? A handful makes wildcards reasonable. Dozens across different services suggests individual certificates.

Do subdomains have different security requirements? If yes, don't share a private key between them.

Am I paying for certificates? Wildcards save money. With Let's Encrypt, that argument disappears.

Can I secure one private key very well? If yes, wildcards concentrate your security effort. If key management is already a weakness, wildcards amplify that weakness.

How painful is certificate management? With modern automation, individual certificates aren't much harder than wildcards. The pain that drove people to wildcards has largely been solved.

For most modern deployments—especially those using Let's Encrypt—individual SAN certificates provide better security with minimal additional complexity. Wildcards remain useful for development environments and specific commercial scenarios, but they're no longer the default choice they once were.