If your website has subdomains, you have probably run into this problem. You get an SSL certificate for example.com. Then you set up blog.example.com and realize it needs its own certificate. Then shop.example.com needs one. Then app.example.com. Pretty soon you are managing five different certificates with different expiration dates and renewal schedules.
Wildcard SSL solves this. A single wildcard certificate covers a domain and all its subdomains. One certificate, one renewal, one thing to keep track of.
This piece covers what wildcard SSL actually is, how it works, when it makes sense, and what to watch out for.
What a Wildcard Certificate Covers
A wildcard certificate uses an asterisk in the domain field to cover any subdomain at one level.
The Coverage Pattern
A wildcard certificate for *.example.com covers any subdomain directly under example.com. That includes:
- example.com
- example.com
- example.com
- example.com
- anything else that takes the form *.example.com
The certificate works for all of these without needing separate certificates for each one.
What It Does Not Cover
The wildcard only works at one level. A certificate for *.example.com does not cover:
- com itself (the bare domain). Most wildcards include the bare domain explicitly, but check the certificate.
- us.example.com or any other two-level subdomain. These need a separate certificate for *.us.example.com or their own individual certificates.
- org or any other domain. Wildcards are tied to a specific domain.
For multi-level subdomains, you need either multiple wildcard certificates or a multi-domain (SAN) certificate that lists each subdomain explicitly.
Combining With the Bare Domain
Most wildcard certificates include both *.example.com and example.com. This way the certificate covers both the bare domain and any subdomain.
If you buy a wildcard, confirm it includes the bare domain. Some certificates do not include it by default and you have to specify it.
How Wildcard Certificates Work
The technology is the same as any SSL certificate, just with the wildcard pattern in the domain field.
Verification Process
To get a wildcard certificate, you have to prove you control the domain. The verification is done at the root domain level (example.com), not at each subdomain.
For domain-validated wildcards, the verification typically uses DNS validation. You add a specific TXT record to your DNS, and the CA confirms you control the domain.
DNS validation is required for free wildcards from Let’s Encrypt. Paid wildcards may also offer email or file-based validation.
Browser Handling
Browsers handle wildcards transparently. When a visitor connects to blog.example.com, the browser sees that the certificate covers *.example.com and accepts it for the subdomain.
The visitor sees the same lock icon and trust indicators as they would with a single-domain certificate.
Certificate Installation
The certificate gets installed on all servers that handle the subdomains. If you run blog.example.com and shop.example.com on different servers, both servers need the wildcard certificate installed.
This is one of the trade-offs. Spreading the certificate across servers means spreading the private key, which is a security concern in larger setups.
When Wildcard SSL Makes Sense
Wildcards are not always the right choice. They fit specific situations well.
Many Subdomains
If you have five or more subdomains, a wildcard is usually more practical than managing five separate certificates. The administrative savings add up.
Subdomains Created Dynamically
If your application creates subdomains on the fly (multi-tenant SaaS where each customer gets a subdomain), a wildcard is essential. You cannot issue a new certificate for each customer every time someone signs up.
A wildcard covers any subdomain that gets created without further setup.
Centralized Management
If one team or person manages all the subdomains, a wildcard simplifies their work. One renewal, one expiration to track, one certificate to update if something changes.
Cost Considerations for Paid Certificates
If you would otherwise buy multiple paid certificates, a wildcard often costs less than the combined price. Wildcards from commercial CAs run $50 to $200 per year. A handful of individual certificates would cost more.
For free certificates, the cost angle does not apply since they are free either way. The administrative angle still does.
When Wildcard SSL Does Not Fit
Some situations call for different approaches.
Few Subdomains
If you only have one or two subdomains, separate certificates are simpler. The administrative savings of a wildcard do not justify the slightly larger trust footprint.
Strict Security Requirements
A wildcard private key has access to all subdomains. If the key gets compromised, all subdomains are compromised. For high-security environments, keeping certificates separate limits the impact of any single compromise.
This is why some security-conscious organizations avoid wildcards even when they would be convenient.
Decentralized Subdomain Management
If different teams or partners manage different subdomains, a shared wildcard means sharing the private key. This is usually not a good idea. Each team should have their own certificate for their own subdomain.
Specific Validation Levels
Wildcard certificates are available for DV and OV validation but not for EV. If you need EV-level identity verification, you need separate certificates for each subdomain (or use a multi-domain certificate, which is different from a wildcard).
How to Get a Wildcard Certificate
The path depends on what you need.
Free Wildcards from Let’s Encrypt
Let’s Encrypt offers free wildcards using DNS-01 validation. The process is more involved than HTTP validation because it requires adding TXT records to your DNS.
If your DNS provider has API access, automation tools like Certbot can handle the entire process automatically. Without API access, you have to add the TXT records manually each time the certificate renews.
For most hosts that support Let’s Encrypt, the wildcard option is available through the control panel. The host handles the DNS automation behind the scenes.
Paid Wildcards from Commercial CAs
Major CAs like DigiCert, Sectigo, and GlobalSign all sell wildcard certificates. Pricing ranges from $50 to $500 per year depending on the CA and validation level.
Resellers like Namecheap and SSLs.com offer wildcards at lower prices than buying direct.
The process involves submitting a certificate signing request, verifying domain ownership, and waiting for the certificate to issue (minutes to days depending on validation level).
Through Your Host
Some hosts sell wildcard certificates as add-ons to hosting plans. The host handles the purchase, installation, and renewal. Convenient but usually more expensive than buying separately.
Common Wildcard Pitfalls
People stumble in predictable ways with wildcards.
Forgetting the Bare Domain
If your wildcard does not include the bare domain, visitors to example.com (without a subdomain) get a certificate error. Always confirm the certificate covers both.
Sharing Keys Insecurely
The private key for a wildcard gives access to all subdomains. Treating it casually is a security risk. Limit who has access. Rotate the key if you suspect it has been exposed.
Trying to Cover Multiple Domains
A wildcard for example.com does not cover example.org. If you need to cover multiple distinct domains, you need either multiple certificates or a multi-domain certificate that lists each one.
Multi-Level Confusion
Some users assume a wildcard covers all subdomains at any level. It does not. The wildcard works at one level. Multi-level subdomains need their own coverage.
Forgetting Automation Setup
Paid wildcards often have one-year validity. Free wildcards have 90-day validity. If you set up a wildcard but do not configure auto-renewal, you eventually end up with an expired certificate.
Wildcard vs Multi-Domain (SAN) Certificates
These two get confused but they are different.
Multi-Domain Certificates
A SAN (Subject Alternative Name) certificate lists multiple specific domains explicitly. For example, a SAN certificate might cover example.com, example.org, and example.net.
The certificate works for exactly the domains listed. Adding a new domain requires getting a new certificate.
Wildcards Use Patterns
A wildcard certificate covers any subdomain matching a pattern. You do not list each subdomain individually.
The difference is flexibility. Wildcards adapt automatically to new subdomains. SAN certificates require explicit configuration for each domain.
When to Use Each
Use a wildcard when you have many subdomains or expect to add more.
Use a SAN certificate when you have multiple distinct domains, or when you have a fixed set of subdomains and want explicit control over what is covered.
Sometimes the right answer is both. A SAN certificate with wildcard SANs covers multiple distinct domains, each with all their subdomains.
Wrapping Up Subdomain Coverage
Wildcard SSL solves a real problem for sites with multiple subdomains. One certificate covers everything at that level, one renewal handles everything, one thing to manage.
For most sites with two or more subdomains, a wildcard is the right approach. The administrative simplicity is worth the small trade-offs in security footprint. With free wildcards from Let’s Encrypt, the cost reason has disappeared too.
For sites with strict security requirements or decentralized management, separate certificates per subdomain still make sense. The slightly higher administrative overhead is worth the smaller blast radius if any single key gets compromised.
If you are adding subdomains to a site, consider going to a wildcard now rather than building up a collection of individual certificates over time. The transition is easier when you do it intentionally than when you find yourself managing eight separate renewals across the year.
For most use cases, the path is straightforward. Use Let’s Encrypt for free DV wildcards through your host. Move to paid options only if you need OV validation, longer validity, or specific support requirements. The encryption is the same. The functionality is the same. The choice comes down to validation needs and operational preferences.