Wildcard vs SAN Certificates
Coverage: Which Names Each Option Protects
A wildcard vs SAN certificate decision comes down to coverage. A wildcard certificate protects every first-level subdomain of one domain, such as *.example.com. A SAN certificate protects a fixed list of names, which can belong to different domains.
A wildcard suits a domain with many subdomains that appear over time, such as customer sites created by a platform. A SAN certificate suits a small, known set of names, possibly across several domains, such as a company website, its webmail address and a second brand. The two options are described in wildcard SSL certificates and SAN certificates.
Flexibility and Day-to-Day Effort
Wildcards are more flexible. A new subdomain under the covered domain is protected immediately. With a SAN certificate, each new name must be added to the list and the certificate reissued before it can serve HTTPS.
That flexibility has a cost in visibility. Any subdomain that is created, including ones nobody planned, can be served with the same certificate. That is convenient, but it makes it harder to see which names are actually in use. A SAN list is a clear record of the names in service. Cost and support differences are covered in free vs paid SSL certificates.
Risk, Key Sharing and Splitting Certificates
Both options can put many names behind one private key. The difference is scope. A wildcard key secures an open-ended set of subdomains, so a leak affects all of them. A SAN key affects only the names on its list, which can still be many and may include unrelated brands.
Many organisations reduce risk by splitting certificates. They use a wildcard for internal or lower-risk subdomains and separate certificates for public or high-value sites. Combining both in one request is also possible, for example *.example.com together with example.org, as long as every wildcard entry is validated through DNS.
Example: A Software Company Makes Its Choice
A software company runs its main website on example.com and a documentation site on docs.example.com. Each customer also receives a portal name such as acme.portals.example.com, created automatically when an account opens. A wildcard for *.portals.example.com fits the portals. The company's second brand, example-tools.net, is unrelated, so it goes on a separate SAN certificate together with the main site. The company keeps two certificates, each matched to how its names change.
Frequently asked questions
Can one certificate combine a wildcard and other names?
Yes. One certificate can hold a wildcard entry, such as *.example.com, together with other names, such as example.org. Each entry must be validated, and wildcard entries require DNS-based validation. This works well when one domain has many subdomains and other domains need coverage too.
Which option is easier to automate?
Both can be automated with modern issuance tools. A wildcard needs DNS-based validation, so the tool must be able to change DNS records. A SAN certificate can use file-based validation when every listed name points to a publicly reachable server, which can be simpler where DNS access is limited.