What is a multi-domain SSL certificate and when should you use one?

A multi-domain SSL (TLS) certificate is one certificate that lists several different hostnames, such as example.com, shop.example.net and api.example.org, in its Subject Alternative Name (SAN) field. Browsers accept it for any listed name. It differs from a wildcard certificate, which covers many subdomains of a single domain.

How does a certificate list more than one name?

The X.509 certificate standard, profiled in RFC 5280, defines a subject alternative name extension that lets a certificate bind additional identities to its public key. DNS names go in the dNSName entries. A multi-domain certificate is simply one with several of them.

Clients check the hostname they connected to against those entries. RFC 6125 describes how applications verify a service identity: they compare the name they expect with the identifiers in the certificate and, when DNS names are present, use them. The old practice of reading the common name field has faded. Modern clients depend on the SAN entries, so every name you need must be listed there.

How does that differ from a wildcard?

A wildcard certificate carries an entry like *.example.com. RFC 6125 limits where the wildcard character may sit: in the left-most label of the name. In practice that means *.example.com matches www.example.com and api.example.com, but not example.com itself and not a.b.example.com. Many wildcard certificates therefore also list the bare domain as a second SAN entry.

So the two types solve different problems.

• Several unrelated domains: multi-domain works, wildcard does not.
• Unlimited new subdomains: wildcard works (one level), multi-domain needs a reissue for each new name.
• Hostname privacy: a multi-domain certificate lists every name, while a wildcard hides the individual subdomains.

You can also combine them: one certificate with example.com, *.example.com and example.net.

What are the risks of bundling names?

A constructed example: a company puts 15 hostnames, from its marketing site to an internal admin tool, on one multi-domain certificate. The private key is copied to every server that terminates TLS for any of those names.

• Larger blast radius. If the key leaks from the weakest server, an attacker can impersonate every name on the certificate.
• Shared revocation. Revoking the certificate takes all 15 names offline at once.
• Changing membership. Adding or removing a name means reissuing and redeploying everywhere.
• Visible names. Public certificates are logged in public transparency logs, so a hostname like admin-staging becomes discoverable by anyone.
• Mixed ownership. Teams that do not trust each other end up sharing a key.

Wildcards have a similar problem. A key for *.example.com can impersonate any subdomain, including ones created later.

How long do certificates last?

The CA/Browser Forum Baseline Requirements set the rules that public certificate authorities follow, including how long a public TLS certificate may remain valid. Those maximum lifetimes have been shortened over time, so check the current version on the Forum's site before planning renewals. Short lifetimes make automated issuance close to mandatory, and they make bundling more tolerable, because rotating a shared key is a routine job.

What do browsers actually check?

When a client connects, it checks that the certificate chains to a trusted authority, that it is within its validity dates, that it has not been revoked where revocation is checked, and that the hostname matches a SAN entry. A mismatch produces the familiar name error. That is why a certificate for example.com alone fails on www.example.com unless that name is also listed. Check every entry point, including mobile app endpoints and redirects, when you plan a certificate's name list.

How to check or apply this

1. List every hostname you serve and who owns each server.
2. Group names by owner and trust level. Keep internal tools off public certificates where you can.
3. Use a multi-domain certificate for names that run on the same infrastructure and team.
4. Use a wildcard only when subdomains are created often and the key can be protected well.
5. Automate issuance and renewal, and generate a separate private key for each certificate.
6. Check certificate transparency logs for your domains to see what the world sees.

Quick check

Sources

• RFC 5280, Internet X.509 PKI Certificate and CRL Profile
• RFC 6125, Representation and Verification of Domain-Based Application Service Identity
• CA/Browser Forum, Baseline Requirements for TLS Server Certificates

Last reviewed: 18 October 2026.