Common Name is the older certificate field historically used to identify a hostname, while SAN, or Subject Alternative Name, is the modern field browsers now expect for HTTPS identity validation. In current browser behavior, SAN is the authoritative location for hostnames and Common Name alone is no longer enough in many cases. That shift forces organisations to update certificate issuance and renewal practices.
Why Common Name and SAN are not interchangeable
The distinction is about how browsers decide which hostname a certificate is allowed to represent. common name was the older single-name field, but modern HTTPS validation relies on the Subject Alternative Name extension instead. That change matters because certificates now need to express identity in a way that supports multiple DNS names, IPs, and service endpoints without ambiguity.
Common Name still appears in many certificates for compatibility or legacy tooling, but it is no longer the authoritative hostname source for browser trust decisions. In practice, that means the name a user types into the address bar must be present in SAN, and the certificate chain must validate against that SAN entry for HTTPS to work cleanly.
For teams managing certificate issuance, the operational implication is simple: do not treat CN as the place to “fix” hostname coverage. Update issuance templates, automation, and renewal checks so SAN is populated correctly from the start, because a valid keypair with the wrong SAN entries can still fail browser validation.
How browser validation changed certificate identity checks
The move from CN to SAN reflects a broader tightening of identity validation in TLS. Browsers needed a field that could represent multiple valid identities and reduce ambiguity when a certificate covers several names. SAN became that field, while CN became legacy metadata that may still be present but is no longer sufficient on its own for modern HTTPS hostname matching.
This is especially visible in environments that rely on shared infrastructure, reverse proxies, load balancers, or multi-domain services. A single certificate may need to cover several hostnames, and SAN is the mechanism that records those identities explicitly. If the requested hostname is missing from SAN, the certificate may be technically issued but still rejected by the browser as not matching the site.
That difference also explains why older certificate habits break during renewal. A certificate that worked years ago with only a Common Name may stop working after a platform, CA, or browser update. The fix is not a different trust store, it is correct hostname representation in SAN.
What certificate teams should verify before renewal or deployment
Certificate operations should verify the requested DNS names, wildcard scope, and service endpoints before the certificate is issued. SAN must reflect the exact names clients will use, including any alternate hostnames that appear in redirects, APIs, or front-door load balancers. If the operational name differs from the public name, both need explicit review.
It is also worth checking automation paths that generate certificates from templates or discovery data. The most common failure mode is stale inventory, where SAN is built from an incomplete list of hostnames. That creates a certificate that looks correct in the CA workflow but fails at the browser or client layer because the live service has moved ahead of the template.
For practitioners working with machine identity and lifecycle management, the same discipline applies to TLS certificates more broadly. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is a useful reference for the renewal and automation side of that problem, especially when expiry, issuance, and inventory all need to stay aligned.
Risk and Threat Considerations
When SAN is missing or incomplete, the failure is usually immediate service disruption rather than subtle degradation. Browsers reject the hostname mismatch, users see trust errors, and automated clients may refuse the connection entirely. In larger estates, the real risk is not only a broken site, but an inconsistent certificate process that allows different teams to issue certificates with different naming assumptions.
Failure mechanism: The certificate validates cryptographically but does not validate for the hostname in use, because the authoritative identity field does not include the requested name.
Impact: Users lose access, APIs fail, and renewal incidents can cascade when multiple services share the same issuance pattern or template.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63, NIST SP 800-57 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers certificate and secret lifecycle discipline for HTTPS identity material. |
| Recommendation — Track certificate issuance, renewal, and rotation as managed authenticators. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Hostname validation and TLS trust sit within modern digital identity assurance practices. |
| Recommendation — Align certificate identity checks with current browser validation expectations. | ||
| NIST SP 800-57 | Key Management | TLS certificates depend on secure lifecycle handling of the keys they bind. |
| Recommendation — Protect private keys and rotate them with certificate renewal. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Certificate identity fields and private keys are authentication information that must be controlled. |
| Recommendation — Govern certificate material and validation data under formal access and issuance controls. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Modern HTTPS identity validation is part of broader trust in authenticated web connections. |
| Recommendation — Verify that client-side trust checks use the authoritative identity field. | ||
Practitioner Guidance
What to verify: Check the exact DNS names that clients use, not just the internal service name or the domain shown in the certificate request. If the certificate will front multiple services, confirm every intended hostname is present in SAN before you approve issuance.
Common mistake: Treating Common Name as a fallback identity field during renewal. That assumption is often what turns a routine certificate refresh into an outage when browsers, libraries, or managed platforms enforce SAN-only matching.
Decision rule: If a certificate is meant for HTTPS browser trust, make SAN the source of truth for hostname coverage and treat CN as legacy context only. If the required name is not in SAN, do not deploy the certificate and do not rely on later browser compatibility.
Practitioner takeaway: The practical shift is from “does the certificate mention the name somewhere?” to “is the name explicitly represented where modern clients actually validate it?”
Related resources from NHI Mgmt Group
- What is the difference between a SAN certificate and issuing separate certificates for each website?
- What is the difference between SSL certificates and HTTPS in everyday website security?
- What is the difference between Wildcard SSL certificates and SAN SSL certificates for mobile app security?
- What is the difference between using a Distinguished Name and a SAN as the identifier in certificate-based authentication?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
