Two sites can share one certificate if, and only if, both hostnames are listed in that certificate's SAN field. There's no other mechanism — a certificate strictly covers the exact hostnames it was issued for.
The three practical setups
- Single-domain certificate — covers one exact hostname only
- Wildcard certificate — covers one domain and all of its first-level subdomains under a single SAN entry
- Multi-domain (SAN/UCC) certificate — covers a specific list of separate, named domains and subdomains you choose when ordering
Why this matters when planning
If you're managing several related subdomains, a wildcard is usually the simplest option. If you're managing several entirely separate domains (not subdomains of one another), you need a multi-domain certificate, or separate certificates per domain — a wildcard cannot help you there, since it only extends to subdomains of the one domain it's issued for.
Why 'sharing' really means being listed together on one certificate
There's no separate mechanism for two unrelated sites to informally share a certificate — the only way two hostnames are covered by the same certificate is if both are explicitly listed in that certificate's SAN field, whether through a wildcard's subdomain coverage or a multi-domain certificate's specific list.
What happens if you try to serve an unlisted hostname with an existing certificate
A browser will reject the connection as a hostname mismatch if the domain being visited isn't included in the certificate's SAN field, regardless of how closely related the two domains might otherwise be — there's no partial or implicit coverage extended to a domain not explicitly listed.
What happens if you add a new subdomain after your certificate was already issued
A newly added subdomain not already covered by an existing wildcard or multi-domain certificate needs its own coverage added, either by reissuing the existing certificate with an updated SAN list, or by obtaining a separate certificate specifically for the new hostname.
What happens technically when a browser checks a SAN list during the handshake
During certificate validation, the browser compares the exact hostname it's connecting to against every entry in the certificate's SAN field — a match on any single entry is sufficient for the hostname check to pass, regardless of how many other, unrelated hostnames the same certificate might also cover.
Why one certificate per server is a common misconception worth correcting
A single server can serve multiple different certificates for different hostnames via SNI, and a single certificate can cover multiple hostnames via its SAN list — there's no inherent one-to-one relationship between servers and certificates in either direction, despite this being a common simplifying assumption.
The simplest way to remember how this actually works
Coverage is always explicit, listed directly in a certificate's SAN field, never implicit or inferred from a shared server, shared IP, or related domain name — if a hostname isn't listed, it isn't covered, regardless of how closely related it might otherwise seem.
What a practical example of legitimate certificate sharing looks like
A company running yourcompany.com, blog.yourcompany.com, and shop.yourcompany.com under one wildcard certificate is a common, entirely legitimate example of certificate sharing — all three are related properties of the same organization, explicitly covered by the same certificate's SAN configuration.
A closing thought
A quick closing thought: coverage is always explicit and listed, never implicit — a simple rule that resolves most confusion about what a given certificate does and doesn't actually cover.