What Is SAN?

At a glance

Modern browsers primarily use SAN to match the requested hostname. One certificate may cover an apex domain, several subdomains or wildcard names.

Why SAN is the modern certificate's name list

Subject Alternative Name is an X.509 extension listing covered DNS names, IP addresses or other identities. Modern browsers primarily match the requested address against SAN rather than the historical Common Name in Subject. A certificate issued by a trusted CA can still fail if the name does not match.

One certificate can cover example.com, www.example.com and several service subdomains, or include wildcard names. This simplifies deployment, but certificate transparency exposes public certificate names. Wider coverage may also increase the impact of key compromise or misconfiguration.

Matching exact names, wildcards and IP addresses

• An exact DNS SAN matches its stated name. www.example.com does not automatically cover example.com; normally both need to be listed.
• *.example.com generally matches one label, such as shop.example.com, but not example.com or a.shop.example.com.
• HTTPS access by IP requires a corresponding IP-address SAN. Placing the numeric address in a DNS-name SAN normally does not provide the right match.
• Internationalized names often appear in ASCII-compatible form. A display can show the readable name, while validation still uses the normalized identity.

Operational and privacy effects of multi-domain certificates

Combining product domains reduces certificate count, but a failed validation during renewal can affect the entire certificate. Sharing a private key across teams also widens the management boundary. Larger deployments often divide certificates by risk, lifecycle and service ownership.

SAN can disclose unreleased project names or internal naming conventions, and certificate transparency makes public certificates searchable. Avoid putting unnecessarily private hostnames into public certificates; use an appropriate private trust system for internal services.

Practical use and interpretation

The returned SAN list can be compared directly with the requested hostname. A match confirms a connection-identity fact. Other names on the certificate share certificate coverage, but do not by themselves establish common business ownership, shared hosting or current availability.

Incomplete certificate data or TLS termination at a CDN leaves the origin certificate's coverage unknown. Public SAN describes the observed edge connection, not the certificate design of the entire infrastructure.

Points to consider

If the requested name is outside the SAN coverage, browsers normally show a certificate-name mismatch warning.

Frequently asked questions

Does a wildcard certificate cover the apex domain?

Usually not. *.example.com covers one-level subdomains; example.com must be listed separately.

Do multiple brand names in SAN belong to the same company?

Not necessarily. Shared hosting, CDNs, multi-tenant platforms and centralized certificate services can put unrelated domains on the same certificate.

Which matters when Common Name and SAN disagree?

Modern clients primarily validate against SAN. Common Name is historical and should not be relied on to replace a missing or mismatched SAN.