Wildcard vs SAN Certificates: Coverage, Limitations, Security, and Cost
Wildcard and multi-domain SAN certificates can both reduce the number of SSL certificates an organization manages, but they solve different problems. A wildcard certificate is designed for many sibling subdomains under one base domain. A SAN certificate explicitly lists multiple hostnames and can cover different base domains. The right choice depends on domain structure, validation, private-key exposure, renewal workflows, and the impact of a certificate failure—not price alone.
This article was reviewed on August 4, 2026. Domain limits, validation requirements, features, and prices vary by certificate authority and platform. Check the current product page, control panel, and service terms before purchasing or deploying a certificate.
Wildcard vs SAN Certificates at a Glance
| Comparison | Wildcard certificate | Multi-domain SAN certificate |
|---|---|---|
| Coverage model | Uses a name such as *.example.com to cover sibling subdomains | Lists each protected hostname in the Subject Alternative Name extension |
| Different base domains | One wildcard does not cover unrelated base domains | Can cover example.com, example.net, and other domains |
| Adding hostnames | A new matching subdomain usually requires no certificate reissue | A hostname not already listed normally requires a reissue |
| Name visibility | Shows the wildcard name rather than every deployed subdomain | Listed SAN hostnames are normally publicly visible |
| Private-key risk | A shared key can expose many subdomains if compromised | The affected scope depends on all names and systems sharing the key |
| Typical use | Many predictable subdomains under one domain | Multiple brands, base domains, or a fixed hostname inventory |
What Does a Wildcard Certificate Cover?
A certificate for *.example.com normally matches:
www.example.comapi.example.comshop.example.com
It normally does not match:
example.com, because the apex domain is not a wildcard match.v2.api.example.com, because it is one level deeper.example.net, because it is a different base domain.
If you need both the apex domain and its first-level subdomains, a common configuration places both example.com and *.example.com in the same certificate. Always inspect the actual SAN list instead of assuming that the wildcard automatically includes the base domain.
Practical rule: the asterisk normally replaces one complete domain label. In*.example.com, it can replacewww, but it cannot replace the two labelsv2.api.
How Does a Multi-Domain SAN Certificate Work?
SAN stands for Subject Alternative Name. Modern TLS clients primarily validate the requested hostname against the SAN extension. One certificate can explicitly include names such as:
example.comwww.example.comapi.example.netshop.example.org
The names may belong to different base domains or to different subdomains of the same domain. The certificate is valid only for the listed names. If cdn.example.net is added later and is absent from the SAN list, the certificate must normally be reissued or another certificate must be deployed.
A SAN certificate may also contain wildcard names. For example, one certificate could include example.com, *.example.com, and example.net. Whether this is supported, how many names are allowed, and how they are priced depends on the certificate authority and product.
How Do Validation Requirements Differ?
Before issuing either certificate type, the certificate authority must verify control of the relevant domains. In an ACME-based workflow, wildcard certificates generally require DNS-01 validation. This involves creating a designated TXT record in DNS. HTTP-01 cannot demonstrate control over an arbitrary set of subdomains and therefore cannot be used to issue an ACME wildcard certificate.
For a SAN certificate, every requested name must be covered by the applicable domain-control validation. Validation and renewal become more complicated when domains are hosted in different DNS accounts or managed by different teams.
If DNS API credentials are used for automation, apply least privilege. Limit the credentials to the required DNS zones and, where supported, to the records needed for validation. Do not place unrestricted DNS credentials on every web server.
Which Certificate Type Is More Secure?
Neither certificate type is automatically more secure. TLS security depends heavily on where the private key is stored, how many systems can access it, and how large the affected scope would be after a compromise.
Wildcard Certificates Concentrate Risk
If the same wildcard certificate and private key are copied to many servers, a compromise of one poorly protected test server may endanger other subdomains covered by that key. The more systems and teams share the key, the harder it becomes to track copies and rotate the certificate safely.
Large SAN Certificates Also Create a Shared Failure Domain
Combining many important domains into one SAN certificate can create a similar risk. A private-key leak, accidental revocation, deployment error, or failed renewal may affect every listed hostname at once.
Safer Deployment Principles
Do not make unrelated systems share a private key merely to reduce certificate count.
Use separate certificates and private keys for production, testing, and development.
Where practical, keep certificates and keys inside a managed certificate service, load balancer, or CDN.
Automate renewal and monitor expiration, deployment status, and revocation.
Split certificates along real security and operational boundaries.
How Should You Compare Wildcard and SAN Certificate Costs?
Statements such as “wildcards always cost more” or “SAN certificates are always cheaper” are unreliable. Free automated certificates, commercial DV, OV, and EV products, exportable certificates, and cloud-managed certificates use different pricing models.
The full cost normally includes:
Certificate charges: base price, included SAN count, extra-name charges, and validation level.
Operational work: ordering, DNS validation, deployment, renewal, replacement, and troubleshooting.
Infrastructure: certificate management, key protection, automation, and monitoring.
Risk: the possible business impact of a key leak, failed renewal, or mistaken revocation.
When a service continuously creates subdomains under one base domain, a wildcard can reduce repeated issuance and deployment work. When the hostname list is stable but spans several base domains, a SAN certificate may be more direct. If the applications are operationally unrelated, several smaller certificates may be safer and easier to manage than one certificate with a very large scope.
Which Certificate Should You Choose?
| Scenario | Evaluate first | Reason |
|---|---|---|
| Many sibling subdomains under one base domain | Wildcard certificate | New matching subdomains usually require no certificate change |
| Several brands or unrelated base domains | SAN certificate or separate certificates | Different domains can be listed explicitly or split by business boundary |
| SaaS creates a subdomain for each customer | Wildcard or platform-managed certificate | Works well for dynamic customer.example.com names, with careful key control |
| A small, stable hostname list | SAN certificate | Coverage is explicit and easy to audit |
| Systems belong to different teams or security levels | Separate certificates | Reduces shared-key exposure and the impact of one failure |
| A CDN or load balancer terminates TLS centrally | Managed certificate | Can simplify renewal and avoid distributing private keys |
What Should You Check When Deploying on a CDN?
First, determine whether the CDN issues a managed certificate, accepts an imported certificate, or integrates with a cloud certificate service. Confirm that every accelerated hostname appears in the certificate’s SAN list. Successfully adding a hostname to the CDN configuration does not prove that the active certificate covers it.
Second, treat edge TLS and origin TLS as separate connections. Visitors validate the CDN edge certificate, while the CDN validates the origin certificate. The edge may use a wildcard certificate while the origin uses a smaller certificate, provided that the origin hostname, trust chain, and CDN validation settings are correct.
Finally, do not distribute private keys through email, chat, or a public source-code repository. For an imported certificate, document its hostnames, deployment locations, expiration date, and owner. During replacement, verify that every edge location or load-balancer node has received the new certificate.
Common Misconceptions
A Wildcard Covers Every Subdomain Level
It does not. *.example.com normally covers one level, not v2.api.example.com.
A Wildcard Automatically Includes the Apex Domain
Not necessarily. Verify that example.com is separately included in the SAN list.
SAN Hostnames Are Private
Names in a publicly trusted certificate can normally be viewed through the TLS handshake and certificate-transparency records. Do not treat an internal hostname in a public certificate as confidential information.
More Hostnames on One Certificate Always Save Money
A larger certificate can increase coordination, change frequency, and failure impact. Fewer certificates do not automatically mean a lower total cost.
Pre-Purchase Checklist
List every base domain and subdomain that requires HTTPS.
Map the domain hierarchy and confirm which names a wildcard would actually match.
Check whether the apex domain must be added as a separate SAN.
Estimate how often new subdomains or base domains will be added.
Identify every server, CDN, and load balancer that will use the certificate.
Evaluate the private-key sharing scope and compromise impact.
Define validation, automated renewal, deployment, and expiration monitoring.
Compare certificate fees, extra SAN charges, operational effort, and risk.
Frequently Asked Questions
Does *.example.com include example.com?
Usually not. If both are needed, make sure the SAN list contains both example.com and *.example.com.
Can a SAN certificate include a wildcard name?
Yes, if the certificate authority and product allow it and the required domain-control validation is completed.
Can one wildcard certificate be installed on multiple servers?
Technically yes, but this usually means copying the same private key to multiple systems and increasing the impact of a key compromise. Consider centralized TLS termination or separate certificates.
Which type is better for CloudFront or another CDN?
It depends on the accelerated hostnames. A wildcard can suit many dynamic subdomains under one base domain. SAN or separate certificates can suit several distinct base domains. You must also follow the CDN’s certificate-region, validation, and hostname-count requirements.
Conclusion
A wildcard certificate offers flexible coverage for sibling subdomains under one base domain. A SAN certificate explicitly covers multiple hostnames and can span different base domains. Both can simplify certificate management, but both can also increase risk when too many systems share one private key.
Choose a wildcard when matching subdomains change frequently. Evaluate a SAN certificate when the hostname list is stable but spans multiple domains. Use separate certificates when systems belong to different teams or security boundaries. The final decision should be based on domain structure, automation, private-key management, and failure impact rather than a single advertised price.
CloudFlew provides CDN and SSL-related services. Before deployment, verify hostname coverage, the certificate chain, private-key matching, and origin HTTPS configuration. Current product pages and service terms should remain the final authority for platform-specific features and charges.
References
Let's Encrypt: Challenge Types, reviewed August 4, 2026
AWS Certificate Manager: Certificate Characteristics, reviewed August 4, 2026
AWS Certificate Manager: Supported Certificate Types, reviewed August 4, 2026
CA/Browser Forum: TLS Baseline Requirements, reviewed August 4, 2026
