Wildcard vs SAN Certificates: Which Do You Need?

Pick a wildcard certificate when you need to secure many subdomains under one base domain, and pick a SAN (multi-domain) certificate when you need to cover a specific list of different hostnames. Both rely on the same field inside the certificate, so the choice comes down to how your names are structured and how you want to manage risk. If you want the underlying mechanics first, start with SSL/TLS certificates explained.

The deciding factor is the Subject Alternative Name (SAN) field. Every modern certificate lists the names it is valid for there, and browsers match the address you visit against that list. A wildcard entry is just a SAN value with an asterisk; a multi-domain certificate is just a SAN field with several literal names. Understanding that one field, described in the X.509 certificate profile, removes most of the confusion. For a refresher on reading these fields, see SSL/TLS certificates explained.

The SAN field, briefly

Historically the hostname lived in the certificate's Common Name. That field is deprecated for this purpose. Today the SAN extension is authoritative, and the CA/Browser Forum requires it: clients ignore Common Name and check SAN entries instead. A single certificate can hold dozens of SAN values, mixing literal names and at most one wildcard label per entry.

Wildcard certificates

A wildcard certificate uses an asterisk in place of the leftmost label, written as *.example.com. It validates every subdomain that sits exactly one level below the base domain. So shop.example.com, api.example.com, and blog.example.com all pass against *.example.com with no extra issuance.

The limitation catches people out: the asterisk replaces one label only. *.example.com does not match the bare example.com, and it does not match a deeper name like api.staging.example.com. To cover the apex too, most teams add example.com as a second SAN value alongside the wildcard.

Wildcards shine when subdomains come and go often. Spin up feature-42.example.com for a demo and it is already trusted, with no certificate request and no waiting.

SAN (multi-domain) certificates

A SAN certificate, often sold as a multi-domain or UCC certificate, names each host explicitly. One certificate might carry example.com, example.net, shop.example.org, and mail.acme.io together. The names need not share a base domain, which makes this format useful for an organisation that runs several brands or product domains from one platform.

The trade-off is maintenance. Every new hostname means reissuing the certificate with an updated SAN list, then redeploying it. That is fine for a stable, known set of names and tedious for a fast-changing one.

Single-name certificates

The simplest option secures exactly one hostname, such as www.example.com (typically with the apex added). For a single site with no subdomains to worry about, this is cheap, easy to automate, and limits exposure to one name.

How they compare

Type	What it covers	Example	Best for
Single-name	One specific hostname	www.example.com	A single site or service
Wildcard	All first-level subdomains of one base domain	*.example.com	Many, changing subdomains under one domain
SAN / multi-domain	An explicit list of distinct hostnames	example.com, app.example.net, mail.acme.io	Several brands or domains on one platform

How to choose

Map your names first. One host? Take a single-name certificate. A growing set of subdomains under a single domain? A wildcard removes the reissue treadmill. A fixed list spanning different domains? A SAN certificate fits cleanly. Some teams combine approaches, putting a wildcard and a few literal names in one SAN field, which the CA/Browser Forum Baseline Requirements permit.

A security note

Convenience has a cost. A wildcard's single private key is valid for every subdomain it covers, so if that key leaks, the attacker can impersonate all of them at once. A SAN certificate concentrates risk too, though across a known list rather than an open-ended pattern. Where the blast radius matters, separate certificates per sensitive service contain a compromise better, even if they take more effort to run. Store wildcard keys carefully and rotate promptly on any suspicion.

Want to see which names a live certificate actually covers, and when it expires? Run a free SSL check at DomainIntel, or read how to check a website's SSL certificate for a manual walkthrough.