SAN (Multi-Domain) vs Wildcard Certificates for Subdomains
Both SAN certificates and wildcard certificates solve the same basic problem — covering multiple hostnames with a single certificate — but they solve it with meaningfully different tradeoffs around flexibility, security exposure, and ongoing maintenance, and choosing between them deserves more deliberate thought than simply picking whichever one a hosting provider's control panel defaults to.
What a SAN Certificate Actually Is
A Subject Alternative Name certificate lists an explicit, enumerated set of specific hostnames it covers — example.com, www.example.com, shop.example.com, api.example.com, and any other exact names included at issuance time — rather than matching a pattern. Every modern certificate technically uses the SAN extension even for a single domain (this became a formal requirement across the industry some years ago, replacing the older Common Name-only approach), but "SAN certificate" in casual usage typically refers specifically to one deliberately issued to cover multiple, explicitly listed hostnames together.
The Core Tradeoff: Explicit List vs Pattern Match
A wildcard certificate's single pattern automatically covers any future subdomain matching that pattern with zero additional configuration — register a new anything.example.com subdomain tomorrow, and the existing wildcard certificate covers it immediately, with no reissuance needed. A SAN certificate provides no such automatic coverage — adding a new hostname requires reissuing the entire certificate with the updated list, a process that, while automatable through ACME tooling, still represents a distinct action needed for every newly added hostname, unlike the wildcard's true zero-effort expansion.
Where SAN Certificates Have the Advantage
For an environment where the exact set of hostnames is known, relatively stable, and deliberately curated, a SAN certificate offers meaningful benefits a wildcard doesn't: it can cover multiple genuinely different domains entirely (not just subdomains of one base domain) in a single certificate — something a wildcard, tied to one specific base domain's pattern, simply cannot do at all — and it avoids the security concentration risk discussed in the piece on wildcard certificates elsewhere on this blog, where a single compromised private key exposes every current and future subdomain rather than only the specific, deliberately enumerated hostnames actually included.
Where Wildcard Certificates Have the Advantage
For an environment with a genuinely dynamic, frequently changing, or very large number of subdomains — a SaaS platform provisioning a new customer subdomain automatically as part of its signup flow, for instance — a wildcard's automatic coverage is close to essential, since requiring a certificate reissuance event for every new customer signup would introduce both meaningful operational overhead and a real dependency on that reissuance process succeeding reliably at whatever volume the business operates at.
Combining Both Approaches
It's entirely possible, and often the most practical real-world approach, to combine both strategies: using a wildcard certificate to cover an entire pattern of genuinely dynamic subdomains automatically, while using a separate SAN certificate (or set of individual certificates) for a smaller number of specific, security-sensitive hostnames where the reduced blast radius of a narrower, explicitly enumerated certificate is worth the minor added maintenance overhead of managing that certificate's hostname list separately from the broader wildcard coverage.
The Practical Cost Difference Has Narrowed
Historically, wildcard certificates commanded a meaningfully higher price than an equivalent single-domain or small SAN certificate from traditional paid certificate authorities, reflecting the broader scope of coverage being sold. With Let's Encrypt and similar automated, free certificate authorities now supporting both wildcard and multi-domain SAN issuance (wildcard issuance through Let's Encrypt specifically requires DNS-01 validation, as discussed elsewhere on this blog), the pricing distinction that once meaningfully influenced this choice has largely disappeared for organizations using free, automated certificate issuance, leaving the decision to rest primarily on the genuine operational and security tradeoffs described above rather than cost.
Making the Actual Decision
The practical decision test comes down to two questions: is the actual set of hostnames needed known and relatively stable, or does it grow dynamically and unpredictably; and does the security architecture benefit meaningfully from limiting a single certificate's blast radius, or is the operational simplicity of one certificate covering everything worth more than that narrower exposure. A small business with a fixed, well-known handful of subdomains generally leans toward SAN; a platform business generating customer subdomains programmatically generally leans toward wildcard, often in combination with a separate, more narrowly scoped certificate for its own core administrative and payment infrastructure.
The Takeaway
SAN and wildcard certificates aren't simply interchangeable options distinguished by price — they represent a genuine architectural tradeoff between explicit, curated coverage with a smaller security blast radius, and automatic, pattern-based coverage that scales effortlessly with a growing or unpredictable number of subdomains. The right choice depends on how dynamic an organization's actual subdomain footprint is, not just which option happens to be the default in a given control panel.
Tags: multi-domain SSL, SAN certificates, wildcard certificates