Cybersecurity glossary
What is a Common Name (CN)?
Learn what a certificate Common Name (CN) is, why browsers now prioritize SANs, how legacy CN matching causes outages, and how to configure hostnames correctly.
Definition
The Common Name (CN) is an X.509 distinguished-name attribute historically used to identify the certificate subject—often a hostname for TLS—but modern public TLS validation relies on the Subject Alternative Name (SAN) extension rather than CN alone.
Why Common Name still confuses operators
Certificate wizards, CSR forms, and old blog posts still ask for a Common Name (CN) as if it alone defines HTTPS identity. That mental model is outdated for public TLS: clients match the hostname you navigate to against SANs first, and CAs are expected to place DNS names there.
CN remains visible in certificate subjects and enterprise PKI, so understanding it prevents mis-issuance, confusing “CN mismatch” errors, and incomplete CSRs.
What the CN field actually is
CN is one attribute inside an X.509 subject distinguished name (DN), alongside org and locality fields when present. It is a string, not a special cryptographic control. Security comes from the CA signature and from clients validating names according to policy.
Subject DN attribute
CN sits in the certificate subject, historically labeling a person, device, or hostname.
Legacy TLS identity hint
Older stacks fell back to CN when SANs were absent; modern public TLS de-emphasizes that fallback.
Not a substitute for SAN
Public server certificates need DNS names in Subject Alternative Name entries.
Still seen in tooling
OpenSSL prompts, enterprise CAs, and monitoring UIs often display CN prominently.
How hostname validation works today
Client connects to a hostname
The user or API targets api.example.com and presents that name via SNI where applicable.
Server returns a certificate chain
The leaf certificate contains subject DN (with CN) and extensions including SAN.
Client builds trust in the chain
Path validation checks signatures back to a trust anchor and validity periods.
Client matches the reference identifier
The expected hostname is compared to SAN DNS names (and historically CN in legacy modes).
Mismatch fails closed
If no authorized name matches, TLS identity verification fails even if the chain is otherwise trusted.
CN vs SAN vs other identity fields
| Field | Role in modern TLS | Guidance |
|---|---|---|
| CN | Subject label; legacy hostname fallback | May still be set, but do not rely on it alone for public HTTPS |
| SAN DNS | Primary hostname identity | Include every required FQDN and needed wildcards |
| SAN IP | IP-based identity when required | Use for literal IP endpoints, not as a CN workaround |
| Organization DN fields | Organizational metadata | Useful for display/policy; not a hostname match source |
Operational checklist
- Put every production hostname clients will use into SAN DNS entries before issuance.
- Include apex and www (or other aliases) explicitly when both are served over HTTPS.
- Treat CSR CN as compatibility metadata; verify the issued certificate’s SAN list in staging.
- Monitor for CN-only certificates on public sites—they indicate outdated issuance pipelines.
- Align internal PKI documentation so app teams stop assuming CN matching is enough.
- When debugging hostname errors, compare the connected name to SANs first, not only the CN string.
- For mTLS client certs, define whether CN, SAN URI/email, or SPIFFE IDs are the authoritative identity.
- Automate issuance with ACME or enterprise enrollment so SAN inventories stay complete.
Why “set CN correctly” is incomplete advice
A perfect CN with missing SANs still fails in current browsers. Conversely, a decorative CN with complete SANs works. Security reviews should inventory names clients actually use—load balancer hostnames, alternate domains, preview URLs—and ensure certificates authorize that set.
Enterprise directories sometimes authenticate users by CN. That is a policy choice, not a web standard. Document the authoritative identifier so authorization code does not parse the wrong DN attribute.
The practical takeaway
The Common Name (CN) is a traditional subject label that once doubled as a TLS hostname. For modern public HTTPS, treat SAN as the identity surface that matters, keep CN only as needed for tooling compatibility, and validate certificates against the names your clients truly dial.
Related security terms
Subject Alternative Name (SAN)
The extension modern clients use to match hostnames in TLS certificates.
X.509 Certificate
The certificate format that contains CN and SAN fields.
Certificate Signing Request (CSR)
Where applicants request CN and SAN values before issuance.
Wildcard Certificate
Certificates that cover multiple hosts under one DNS pattern.
HTTPS
HTTP over TLS, where hostname matching against the certificate is enforced.
Frequently asked questions
What is a Common Name in a certificate?
CN is a field in the subject distinguished name. For TLS server certificates it traditionally held the primary hostname, such as www.example.com.
Do browsers still trust the CN for HTTPS hostname checks?
Modern browsers and the CA/Browser Forum baseline require usable DNS names in the SAN extension. A CN without matching SANs is not a reliable way to pass public HTTPS validation.
What is a CN mismatch error?
It usually means the name you connected to is not present in the certificate’s validated names (today, primarily SANs). Users see warnings because identity binding failed.
Should I still set a CN when requesting a certificate?
Many tooling chains still expect a CN for compatibility, but you must also include every needed hostname in SANs. Treat SAN as the source of truth.
Is CN used outside TLS?
Yes. Client certificates, code signing, and enterprise directories may use CN for people, devices, or services. Meaning depends on the PKI policy—not only on web TLS rules.
Can CN contain an IP address?
Historically some certificates put IPs in CN, but IP identity for modern TLS belongs in SAN iPAddress entries. Prefer explicit SAN IP names.
Why do legacy systems still talk about CN?
Older libraries matched hostnames against CN before SAN became mandatory. Documentation and error strings often lag behind current validation rules.
References
Explore authoritative guidance and frameworks related to common name (cn).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.