A Subject Alternative Name (SAN) is a field in a certificate listing every hostname it's valid for. Modern browsers require a certificate's SAN field to include the exact domain being visited — the older "Common Name" field is effectively ignored by current browsers, even though it's still commonly filled in during CSR generation out of habit.
Why it matters for multi-domain and wildcard certificates
A single certificate can cover multiple domains because the CA lists them all in the SAN field — this is exactly how multi-domain (SAN/UCC) certificates work. A wildcard certificate has a single SAN entry like *.yourdomain.com, which matches any first-level subdomain but not the bare domain, which is why yourdomain.com itself is often added as an additional SAN entry alongside the wildcard.
Checking a certificate's SAN list
In Chrome, click the padlock/tune icon → Connection is secure → Certificate is valid → Details, and look at the "Subject Alternative Name" field. If your domain isn't listed there exactly, the browser will show a name-mismatch warning regardless of what the Common Name says.
Why the old Common Name field still shows up even though it's ignored
Certificate generation tools and CSR forms still commonly ask for a Common Name out of long-standing habit, even though modern browsers ignore it entirely for hostname matching — filling it in with your primary domain is harmless and often expected, but it's the SAN field that actually determines what a browser will accept the certificate for.
How SAN entries work for wildcard and multi-domain certificates
A wildcard certificate has a single SAN entry like *.yourdomain.com covering all first-level subdomains; a multi-domain certificate simply lists several specific, separate hostnames as individual SAN entries — both mechanisms use the exact same underlying SAN field, just populated differently depending on what you need covered.
Why a certificate can list far more than just a handful of hostnames
There's no hard technical limit on how many SAN entries a single certificate can contain, though CAs and server software may impose their own practical limits — a multi-domain certificate covering dozens of separate hostnames for a large organization managing many properties isn't unusual in enterprise contexts.
How to check exactly which hostnames a specific certificate covers
Viewing any certificate's details in a browser and looking specifically at the Subject Alternative Name field shows the complete, authoritative list of hostnames that certificate is valid for — this is the definitive source, more reliable than assuming based on the Common Name or the domain you happened to purchase the certificate for.
What happens if a SAN list becomes outdated after a subdomain is retired
There's no requirement to remove an unused hostname from a certificate's SAN list before renewal — an outdated entry covering a retired subdomain simply sits unused and harmless, though it's reasonable practice to clean up the SAN list at your next renewal if you're specifically re-issuing rather than just renewing as-is.
The one field that matters most when something doesn't match
If you're ever troubleshooting a hostname mismatch error, the SAN field is where the actual answer lives — not the Common Name, which modern browsers effectively ignore for this specific purpose.
How to spot a certificate that's been issued with an unnecessarily broad SAN list
A certificate listing many unrelated domains together, rather than domains genuinely belonging to the same organization or purpose, is worth scrutinizing — an overly broad SAN list can indicate a shared hosting certificate covering unrelated third-party sites, worth understanding if you're evaluating a certificate's actual scope.
A closing thought
A quick closing thought: whenever you're troubleshooting an unexpected hostname mismatch anywhere on this site, the SAN field is almost always where the actual, definitive answer lives.