What Is a Wildcard SSL Certificate and When Do You Need One?

If you run a service with multiple subdomains, you have probably run into the question of how to manage SSL certificates across all of them. Issuing a separate certificate for every subdomain is tedious and error-prone. A wildcard SSL certificate solves this by covering an entire level of subdomains with a single cert.

What Wildcard Certificates Cover

A wildcard certificate is issued for a pattern like *.example.com. The asterisk matches any single label in the leftmost position of the domain. So a certificate for *.example.com covers www.example.com, app.example.com, api.example.com, blog.example.com, and any other direct subdomain of example.com.

The important caveat is depth. A wildcard certificate does NOT cover sub-subdomains. *.example.com does not cover dev.api.example.com. If you need to cover multiple levels, you would need a separate wildcard certificate for *.api.example.com or use a multi-domain certificate that lists each name explicitly.

The root domain itself is also not automatically covered. *.example.com does not cover example.com unless the certificate explicitly includes both the wildcard and the apex domain as a Subject Alternative Name.

How Wildcard Validation Works

Standard domain validation for a specific hostname can be done by serving a file over HTTP or adding a DNS TXT record. For a wildcard certificate, because you are claiming authority over an entire subdomain namespace, certificate authorities require DNS validation. You must add a TXT record to your DNS zone, which proves you control the zone itself rather than just one hostname in it.

This is worth knowing because it means wildcard certificate renewal cannot be fully automated the same way single-domain HTTP validation can unless your DNS provider has an API and your certificate client supports it. Tools like Certbot have DNS plugins for many popular providers including Route 53, Cloudflare, and DigitalOcean DNS that make automated wildcard renewal straightforward.

Wildcard vs Multi-Domain Certificates

A multi-domain certificate, also called a Subject Alternative Name certificate or SAN certificate, lists specific hostnames explicitly in the certificate rather than using a wildcard pattern. For example, it might cover www.example.com, api.example.com, and shop.example.com as distinct entries.

The trade-offs are meaningful. A wildcard automatically covers new subdomains you create in the future without any certificate changes. A SAN certificate requires reissuance every time you add a new subdomain. On the other hand, a wildcard certificate is somewhat higher risk: if the private key is compromised, every subdomain is affected. A SAN certificate limits the blast radius to the domains explicitly listed.

Security Considerations

Because a single private key covers all subdomains, wildcard certificate key management is more sensitive than for single-domain certificates. Store the private key with appropriate access controls. Be cautious about deploying the same key and certificate to servers that have different trust levels. A compromised development or staging server that shares the same wildcard cert as production can expose your production domains.

Some organisations use a wildcard certificate on their CDN or load balancer tier while issuing more specific certificates to backend services. This is a reasonable middle ground that takes advantage of wildcard convenience at the edge while limiting exposure in internal infrastructure.

Let us Encrypt and Wildcard Certificates

Let us Encrypt has supported wildcard certificates since 2018 using the ACMEv2 protocol. They are free like all Let us Encrypt certificates but require DNS-01 challenge validation as described above. The 90-day validity period is the same as for other Let us Encrypt certificates, so automated renewal with DNS API integration is strongly recommended.

When a Wildcard Makes Sense

A wildcard certificate is a good fit when you have five or more subdomains that need coverage, especially if you are frequently creating new subdomains. SaaS products that provision per-customer subdomains are a classic example. Developer tooling that automatically creates subdomains for deployments or review environments is another.

For a simple site with www and mail, a wildcard is probably overkill. For anything with a dynamic or growing set of subdomains, it quickly pays for itself in reduced operational complexity.