The Subject Alternative Name extension is the authoritative list of hostnames and IP addresses a TLS certificate covers. Browsers use the SAN list exclusively to decide whether a certificate is valid for the host they are connecting to — the older Common Name field is ignored for this purpose.
Early TLS certificates used the Subject field's Common Name (CN) attribute to identify the hostname a certificate was issued for. As multi-domain and wildcard certificates became common, the CN became inadequate — it holds a single string, has no formal hostname semantics, and no extension point for additional names.
The X.509 Subject Alternative Name extension was defined to solve this. It carries a typed list of identities: DNS names, IP addresses, email addresses, and URIs. For web PKI, DNS names and IP addresses are what matter. Around 2017, Chrome 58 stopped honoring the CN for hostname verification and required a matching SAN entry instead. Other major browsers followed, and the CA/Browser Forum Baseline Requirements now mandate that all TLS certificates for public domains include the hostname in the SAN extension.
Because a SAN extension can carry multiple DNS name entries, a single certificate can cover many unrelated hostnames. These are often called SAN certificates or multi-domain certificates. Hosting providers and CDNs issue shared certificates that list dozens or hundreds of customer domains as SAN entries, reducing the number of certificates they must manage.
There is no hard limit in the X.509 standard on the number of SAN entries, but CAs and browsers may impose practical limits. The CA/Browser Forum Baseline Requirements impose validity and naming constraints but do not cap SAN count.
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:api.example.com
A SAN entry can be a wildcard DNS name such as *.example.com. A wildcard matches exactly one label to the left of the dot — it covers www.example.com and api.example.com but not example.com (the apex) nor sub.api.example.com (two levels). To cover both the apex and the wildcard, a certificate needs two SAN entries: example.com and *.example.com.
All publicly trusted TLS certificates must be logged in Certificate Transparency logs before browsers will trust them. Because CT logs are public and indexed, every SAN entry — every hostname listed in every certificate — is visible to anyone. This means subdomains that appear only in certificate SANs are discoverable through CT log searches, even if they are not linked from any page and not returned by DNS. Security researchers and attackers routinely enumerate a target's infrastructure this way.
If a subdomain should remain non-public, issuing a certificate for it causes immediate disclosure. Consider whether a service genuinely requires a publicly trusted certificate, or whether it can be served over a private PKI instead.
Inspect certificate SANs with the TLS tool
Open TLS Inspector