Certificates come in three practical shapes based on what they cover: a single hostname, a domain plus all of its subdomains, or a specific list of separate domains. Picking the wrong shape is one of the most common certificate-buying mistakes, because the names sound similar but solve entirely different problems.
Single-domain certificates
Covers exactly one hostname — typically either yourdomain.com or www.yourdomain.com, though modern issuance commonly includes both as SAN entries automatically. It does not cover any other subdomain. If you later add shop.yourdomain.com, that needs its own certificate (or you need to upgrade to a wildcard).
Wildcard vs multi-domain, side by side
Wildcard certificates in more detail
A wildcard certificate uses a single SAN entry like *.yourdomain.com, which matches any first-level subdomain: shop.yourdomain.com, blog.yourdomain.com, api.yourdomain.com, all under one certificate. Two important limits: it does not match the bare domain yourdomain.com itself (that's typically added as a second SAN entry), and it does not match a second-level subdomain like a.b.yourdomain.com — the wildcard only extends one level deep.
Multi-domain (SAN / UCC) certificates in more detail
A multi-domain certificate lists a specific, explicit set of hostnames you choose at order time — which can be entirely unrelated domains, not just subdomains of one root domain. This is the right shape for an agency managing several client domains under one renewal cycle, or a business operating under multiple brand domains that all need to be covered without managing a separate certificate (and separate renewal schedule) for each.
Choosing between them
- Securing many subdomains of one domain → wildcard, generally simpler and often cheaper for that specific use case
- Securing several genuinely separate domains → multi-domain, since a wildcard cannot extend across different root domains
- Securing just one hostname → single-domain, the simplest and usually cheapest option, and the right default unless you specifically anticipate growth into subdomains
A subtlety worth knowing: wildcard scope and internal security
Because a wildcard certificate's private key can decrypt traffic for every subdomain it covers, compromising that one key exposes every subdomain at once — including ones added after the certificate was issued. For environments with strict internal security boundaries between subdomains (e.g. a customer-facing subdomain and an internal admin subdomain), some organizations deliberately avoid wildcards for exactly this reason, preferring individual certificates so a single key compromise has a smaller blast radius.
Combining approaches: wildcard SAN entries on a multi-domain certificate
The two shapes aren't always mutually exclusive. Many CAs support ordering a multi-domain (SAN) certificate where one or more of the listed SAN entries is itself a wildcard — for example, a single certificate covering yourdomain.com, *.yourdomain.com, and yourotherdomain.com together. This is worth knowing about specifically because it can save real money and management overhead for an organization running a handful of separate domains, each with their own set of subdomains, without needing a fully separate certificate per domain.
How pricing tends to scale across the three shapes
As a rough rule, single-domain certificates are cheapest, wildcards cost more than a single-domain certificate but typically less than buying that same number of subdomains as individual certificates, and multi-domain certificates are usually priced per additional domain added beyond a base number included in the certificate. Free options complicate this comparison somewhat — Let's Encrypt issues free wildcard certificates (via DNS validation) and free multi-domain certificates alike, which is part of why cost has become a smaller factor in this decision than it used to be, leaving the actual coverage shape as the more important thing to get right.
Renewal and validation differences worth planning around
Wildcard certificates, because they only ever cover subdomains of a single domain, typically renew with a single, simple domain-control validation step (proving control of the base domain, usually via a DNS TXT record). Multi-domain certificates, covering several separate domains, generally require validating control of every listed domain independently at each renewal — which means a multi-domain certificate's renewal can fail, or partially fail, if you've lost DNS or hosting control of even one of the listed domains, while the others remain fine. For anyone managing certificates at scale, this is a real operational difference, not just a pricing one.
A quick decision test you can apply immediately
If every hostname you need to cover shares the exact same root domain and is a first-level subdomain of it, a wildcard fits cleanly. The moment you need to cover a genuinely different domain name — not a subdomain, but an entirely separate registered domain — you need a multi-domain certificate instead, since a wildcard has no mechanism to extend across domain boundaries.
What happens if your subdomain needs grow after you've already bought one type
Certificates aren't rigidly locked to their original scope forever — if you started with a single-domain certificate and later need subdomain coverage, you simply purchase or issue a new wildcard certificate and replace the old one; there's no requirement to keep using whatever type you originally chose. This flexibility is part of why it's reasonable to start with the simplest option that covers your current needs rather than over-provisioning for hypothetical future growth.
Combining both shapes on one multi-domain certificate
Many CAs support ordering a multi-domain certificate where one of the listed entries is itself a wildcard — for example, one certificate covering yourdomain.com, *.yourdomain.com, and yourotherdomain.com together. This can save real management overhead for an organization running a handful of separate domains, each with their own subdomains.
The security trade-off of a wildcard's broad coverage
Because a wildcard certificate's private key can decrypt traffic for every subdomain it covers, compromising that one key exposes every subdomain at once, including ones added after issuance. For environments with strict internal boundaries between subdomains, some organizations deliberately avoid wildcards for exactly this reason, preferring individual certificates with a smaller blast radius per key.
Whichever shape fits your situation, the underlying certificate mechanics, encryption strength, and installation process are identical — the only real decision is which specific set of hostnames you need one certificate to cover.
A quick closing checklist for choosing between them
List every hostname you need covered, check whether they're all subdomains of one root domain, and confirm whether DNS-01 validation (required for wildcards) is feasible with your DNS provider — three questions that reliably point to the correct choice.