Key Points
- A subject alternative name is an extension to the X.509 certificate standard that lets a single certificate bind to multiple identities, such as domain names, IP addresses, email addresses, and user principal names.
- The CA/Browser Forum mandated SAN inclusion in all publicly trusted TLS certificates in 2012, and Chrome 58 removed common name fallback in 2017, making the SAN extension the only field browsers check for hostname validation.
- SAN certificates can secure dozens to hundreds of distinct identities under one certificate, eliminating the overhead of managing separate certificates per domain or endpoint.
- In 802.1X network authentication, the SAN carries the user principal name or device DNS name that a RADIUS server reads to grant or deny access, making accurate SAN configuration a prerequisite for EAP-TLS deployments.
Every organization running HTTPS, Wi-Fi, or virtual private network (VPN) authentication depends on the subject alternative name field, often without realizing it.
Misconfigure it and browsers display security errors. Leave it out of a client certificate and your Remote Authentication Dial-In User Service (RADIUS) server refuses the connection. Get it right and certificate-based authentication becomes nearly invisible to end users.
This guide explains what a subject alternative name is, how it works inside an X.509 certificate, the types of identities it can carry, and why its role in network authentication matters as much as its role in HTTPS.
What Is a Subject Alternative Name?
A subject alternative name (SAN) is an extension to the X.509 certificate standard that allows a certificate to bind to more than one identity.
The SAN extension is codified in RFC 5280, Section 4.2.1.6. RFC 9525 (November 2023) later formalized that server identity may be expressed only in the SAN and that the common name is no longer valid for hostname matching.
Before this extension existed, certificates could only name a single subject in the common name (CN) field. The SAN extension broke that limitation by letting certificate authorities embed a list of identities, called GeneralNames, inside a single certificate.
When a client connects to a server, it reads the SAN list and checks whether the hostname, IP address, or identity it expects to find appears there. If it does, validation succeeds. If it does not, the connection fails regardless of what the common name field says.
RFC 2818 specifies that if a certificate contains a SAN extension, clients must use it for identity matching and must ignore the common name field entirely. Every modern TLS stack enforces this; it’s written into the standard, not a browser-specific behavior.
Types of Subject Alternative Names
RFC 5280 defines nine GeneralName formats that a SAN extension can carry. The ones relevant to most IT environments are:
| SAN Type | Format | Common Use |
| dNSName | Fully qualified domain name | HTTPS server certificates |
| iPAddress | IPv4 or IPv6 address | Internal servers without DNS |
| rfc822Name | Email address | S/MIME email signing |
| uniformResourceIdentifier | URI | Service mesh workload identity (SPIFFE) |
| otherName | Custom OID value | User principal names (UPNs) for 802.1X |
| directoryName | X.500 distinguished name | LDAP-authenticated services |
The otherName type is worth singling out. When the object identifier (OID) inside an otherName SAN is set to the Microsoft UPN OID (1.3.6.1.4.1.311.20.2.3), the SAN carries a user principal name.
This is how client certificates identify users in Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication for 802.1X networks. A RADIUS server reads that UPN, looks it up in the identity provider, and decides whether to grant network access. Without a correctly populated UPN SAN, EAP-TLS authentication fails.
SAN vs. Common Name: What Changed and Why
The common name field in an X.509 certificate once served as the primary field for hostname matching. Browsers and applications would read the CN, compare it to the server’s hostname, and accept or reject the connection based on that comparison. This worked when single-site deployments were the norm, but it created problems as organizations began hosting multiple services on shared infrastructure.
The transition away from CN-based validation happened in two steps:
- 2012 CA/Browser Forum Baseline Requirements: The CA/Browser Forum mandated that certificate authorities include a SAN extension in all publicly trusted TLS certificates. Any domain name present in the common name field must also appear in the SAN.
- April 2017 Chrome 58: Google removed CN fallback from Chrome. Certificates that had a valid CN but no matching SAN entry began triggering ERR_CERT_COMMON_NAME_INVALID errors. Firefox and Safari implemented equivalent enforcement around the same period.
The result is that the CN field in a publicly trusted certificate is now effectively decorative. Browsers read the SAN only. The CN is permitted for backward compatibility with older non-browser clients, but its use for hostname matching is deprecated under both IETF guidance and CA/Browser Forum rules.
SAN and Common Name Comparison
The differences between SAN and common name come down to five practical factors, from what browsers validate to how each field handles 802.1X authentication:
| Factor | SAN | Common Name |
| Browser hostname validation | Required | Completely ignored (post-2017) |
| Multiple identity support | Yes, up to hundreds per cert | No, one value only |
| IETF status | Current standard (RFC 5280, RFC 9525, Nov. 2023) | Deprecated for hostname matching |
| 802.1X client auth | Carries UPN or DNS name | Not used by RADIUS for identity lookup |
| Wildcard support | Yes, via dNSName wildcard entries | Limited, single-label only |
How SAN Certificates Work
When a certificate authority (CA) signs a certificate, it embeds the SAN extension in the certificate body. The CA signs the entire certificate, including the SAN list, making the SAN tamper-evident. Any modification to the SAN list after issuance invalidates the CA signature and causes validation to fail.
The validation flow for a TLS connection works like this:
- A client initiates a TLS handshake with a server.
- The server presents its certificate.
- The client checks the certificate chain up to a trusted root CA.
- The client reads the SAN extension and compares each entry to the hostname it dialed.
- If any SAN entry matches, validation succeeds and the connection proceeds.
- If no SAN entry matches, the client terminates the connection with a certificate error.
For wildcard SAN entries such as *.example.com, the match covers all single-label subdomains at the same level. The wildcard does not cover the bare domain (example.com) or multi-level subdomains (a.b.example.com).
The Critical Extension Rule
RFC 5280 includes a specific rule about SAN criticality. If a certificate carries naming information only in the SAN extension and the subject distinguished name (DN) field is empty, the SAN extension must be marked as critical. This tells certificate clients that they must process the extension rather than ignore it. Misconfiguring criticality on certificates with empty subject DNs causes authentication failures in strict clients.
Subject Alternative Names in 802.1X Authentication
The SAN field matters well beyond HTTPS. In 802.1X network authentication, certificates serve as device and user credentials for Wi-Fi and VPN access. Both the server certificate (presented by the RADIUS server) and the client certificate (presented by the user or device) depend on correctly configured SANs.
Server Certificate SANs
When a device connects to a WPA2-Enterprise Wi-Fi network, it validates the RADIUS server certificate before sending any credentials. The device checks that the server’s hostname or IP address appears in the RADIUS certificate’s SAN. If it does not, the supplicant rejects the connection. This check prevents connections to rogue access points presenting fraudulent certificates.
Client Certificate SANs for EAP-TLS
In EAP-TLS, the client presents a certificate instead of a password. The RADIUS server reads the client certificate’s SAN to identify who or what is connecting:
- For user certificates, the SAN carries the user’s UPN (via the otherName field).
- For machine certificates, the SAN carries the device’s fully qualified domain name (FQDN) as a dNSName entry.
A RADIUS server with identity-lookup capability reads the UPN or device FQDN from the SAN, queries the identity provider in real time, and validates that the user is active and the device is managed. This is how certificate-based authentication ties access decisions to live identity data rather than to static certificate attributes.
SAN Configuration in Certificate Templates
Enterprises deploying certificate-based authentication through a public key infrastructure (PKI) configure SAN content at the certificate template level. The template defines which fields populate the SAN, whether from Active Directory attributes, mobile device management (MDM) enrollment data, or custom values passed during the enrollment request.
Getting SAN configuration right at the template level is non-negotiable. A SAN that contains a stale UPN, a mismatched FQDN, or no entry at all causes silent authentication failures that are difficult to diagnose because the RADIUS server receives a structurally valid certificate that simply does not match any known identity.
A stale UPN, a mismatched FQDN, or a missing SAN entry produces a structurally valid certificate that no identity matches, so the RADIUS server rejects it with no obvious cause. These silent failures are among the hardest 802.1X problems to diagnose.
Benefits of SAN Certificates
SAN certificates offer operational and security advantages over issuing individual certificates per domain or identity:
- Reduced certificate sprawl: One SAN certificate covering 10 subdomains replaces 10 individual certificates, cutting issuance, renewal, and monitoring overhead by the same factor.
- Simplified renewal cycles: Renewing one certificate updates protection for every identity listed in its SAN, rather than requiring coordinated renewal across multiple certificates with staggered expiration dates.
- Easier load balancer and CDN configuration: Content delivery networks and load balancers often serve multiple domains from shared infrastructure. A SAN certificate covering all domains eliminates the need to route traffic by server name indication (SNI) to separate certificate endpoints.
- Consistent trust anchor: All identities on a SAN certificate share one root CA chain, simplifying trust store management across client devices.
Limitations of SAN Certificates
SAN certificates have constraints that affect both publicly trusted and internal certificates:
- Static identity list: Every SAN entry is locked in at issuance. Adding a new domain or UPN requires issuing a new certificate, which means a new certificate signing request (CSR) and a new CA signature.
- Provider-imposed limits: Public certificate authorities typically cap SAN certificates at a few hundred entries per certificate.
- Wildcard scope limits: A wildcard SAN (*.example.com) covers only single-label subdomains of a single domain. It does not cover the root domain or deeper subdomain levels, and it does not cover other registered domains.
- Revocation granularity: Revoking one identity on a multi-identity SAN certificate revokes all of them. Organizations that need per-identity revocation must issue separate certificates.
- Internal PKI complexity: Generating accurate SAN entries at scale, particularly UPNs that must match live directory data, requires automation. Manual SAN entry is error-prone and does not scale to thousands of devices.
How JoinNow Dynamic PKI Manages Subject Alternative Names
Managing SAN configuration manually works for a handful of certificates. But doing this manually does not work in enterprise environments that issue thousands of client certificates for 802.1X authentication. SAN values must reflect current identity data, and any mismatch between the SAN and the identity provider causes authentication failures.
JoinNow Dynamic PKI can help:
- It automates SAN population at issuance time by reading identity attributes directly from Entra ID, Okta, Google Workspace, or an MDM such as Intune or Jamf.
- The platform constructs each certificate’s SAN using live directory data, so UPNs, device FQDNs, and email addresses in issued certificates reflect the current state of the identity store rather than static template values.
When combined with JoinNow Cloud RADIUS, the UPN or FQDN in the certificate SAN is validated against the identity provider on every authentication attempt, not just at enrollment time. If an account is disabled or a device falls out of compliance after a certificate is issued, the RADIUS server denies access at the next connection attempt. The SAN becomes a live link between the certificate and real-time identity data.
For organizations running 802.1X authentication, accurate SANs are the foundation of every EAP-TLS connection. Getting certificate templates, SAN population, and RADIUS policy aligned is the configuration work that separates a working deployment from one that generates unexplained authentication failures.
To see how Dynamic PKI handles SAN configuration and certificate lifecycle automation for your environment, schedule a demo.
Frequently Asked Questions
How many domains can a SAN certificate cover?
The limit depends on the certificate authority. Some public CAs cap SAN certificates at 100 identities, while others offer certificates covering hundreds of names. Internal PKI systems can be configured to issue certificates with SAN lists as long as the organization’s policy allows.
Can a SAN certificate use wildcards?
Yes. A wildcard SAN entry such as *.example.com covers all single-label subdomains of example.com, for instance, mail.example.com or app.example.com. It does not cover the bare domain example.com, multi-level subdomains such as dev.app.example.com, or other registered domains. Organizations that need to cover both the bare domain and its subdomains must include both example.com and *.example.com as separate SAN entries.
What is the difference between a SAN certificate and a wildcard certificate?
A wildcard certificate secures all single-label subdomains of one domain using a single *.example.com entry. A SAN certificate secures a specific list of named identities, which can include entirely different domains, IP addresses, and user principal names. The two aren't mutually exclusive: a SAN certificate can contain wildcard entries, covering multiple domains and their subdomains in one certificate.
What happens if a certificate has no SAN?
A certificate with no SAN extension will fail validation in all modern browsers and most modern authentication clients, even if the common name matches the expected hostname. Chrome displays ERR_CERT_COMMON_NAME_INVALID in this situation. For internal certificates used in 802.1X authentication, a missing SAN prevents EAP-TLS from completing successfully because the authentication server has no structured field to read for identity matching.
Can you add a domain to an existing SAN certificate?
No. Every SAN entry is fixed at issuance because the CA's signature covers the entire certificate, including the SAN list. Adding a domain or UPN means generating a new certificate signing request and having the CA issue a replacement. This is why organizations with frequently changing identities automate certificate issuance rather than editing certificates by hand.
How do I check the SAN on a certificate?
You can view a certificate's SAN in any browser by clicking the padlock icon and opening the certificate details, where the subject alternative name appears as a list of entries. On the command line, openssl x509 -in cert.pem -text -noout displays the full SAN extension. For 802.1X troubleshooting, checking that the client certificate's SAN contains the expected UPN or FQDN is often the fastest way to diagnose an EAP-TLS authentication failure.
