The Common Name (CN) is a field in the subject of an X.509 certificate – and, separately, an attribute in an LDAP directory entry – that traditionally identifies the certificate holder, such as a server’s hostname or a user’s account name. It is set when generating a certificate signing request and checked when validating a peer certificate.
Key takeaways
- CN identifies a certificate’s subject – a hostname or a user identity.
- Modern TLS validation checks SAN entries, not CN, for hostname matching.
- CN also names LDAP/Active Directory entries, unrelated to certificates.
- A Director node’s CN must exactly match its hostname to install cleanly.
- Versa can map CN to a username for device or user certificate authentication.
On this page: Why it mattersHow it worksWhere does a Common Name appear?Common Name & VersaFAQ
Why is a Common Name important?
A Common Name is the field a client or browser traditionally read to answer a basic security question: is this the server, or person, I meant to reach? During a TLS handshake, clients historically compared the requested hostname against the certificate’s CN; a mismatch triggered a trust warning, since it signaled possible impersonation or misconfiguration. That string, supplied when the certificate’s private key and certificate signing request (CSR) are generated, sits at the center of confirming that both ends of an encrypted connection are who they claim to be.
The stakes are more than cosmetic – a wrong or expired CN breaks automated systems, such as API clients or node-to-node replication, that fail closed rather than connect to an unverified peer. In directory services, CN carries similar weight from a different angle: it uniquely names a person, service account, or container inside an LDAP or Active Directory tree, and administrators depend on it for correct bind and search queries. Getting the CN right, in either context, is a precondition for authentication working at all.
What is a Common Name?
In an X.509 certificate, the Common Name is one of several attributes that make up the certificate’s Subject Distinguished Name, alongside fields such as Organization (O), Organizational Unit (OU), Locality (L), and Country (C). For a server certificate, CN traditionally held the fully qualified domain name the certificate was issued for; for a client or user certificate, it typically holds an individual’s name or account identifier instead. The value is supplied when generating a certificate signing request – the file, containing a public key and these subject fields, that is submitted to a certificate authority (CA) for signing.
The same three letters also describe a related-by-name but distinct concept in directory services: in LDAP and Active Directory, Common Name is the relative distinguished name (RDN) attribute that identifies a single entry – a user, service account, or container – at its position in the directory tree, written as cn=value and combined with other RDNs into a full Distinguished Name.
Where does a Common Name appear?
Server (leaf) certificates. CN historically carried the hostname a TLS server certificate was issued for, supplied alongside the private key when the CSR was created and fixed for the life of the certificate.
Client and user certificates. In mutual-TLS and device- or user-certificate authentication, CN commonly holds a username, device identifier, or full name rather than a hostname, since the certificate’s job is proving an identity rather than a network address.
Self-signed certificates. Tools that generate self-signed certificates for lab, proof-of-concept, or initial-install use still prompt for a CN – usually the local hostname – because the field is mandatory in the X.509 subject even when no external CA is involved.
LDAP and Active Directory entries. Outside PKI entirely, CN is the RDN that names a directory object, appearing inside a Distinguished Name such as cn=Administrator,cn=Users,dc=example,dc=com. This usage predates and is unrelated to its role in certificates, though both trace back to the same X.500 naming conventions.
Common Name & Versa
On a Versa Director node, CN appears at certificate-creation time in two places: the self-signed certificate script prompts for a cn value – the Director node’s hostname – and the CSR-generation script takes a domain field documented as “common name for the active Director node,” which “must be an exact match” to the node’s hostname before a CA-signed certificate installs and validates correctly.
On the SSE Gateway, authentication profiles use CN differently: device- and user-certificate authentication profiles let an administrator choose which field – CN, User Principal Name, or Subject Alternative Name – identifies the connecting user, and matching the certificate’s CN to the username defined in LDAP or SAML is documented as a way to stop a shared device from being spoofed as multiple identities. The same letters also appear in LDAP Bind DNs used for directory authentication, for example cn=Administrator,cn=Users,dc=versa,dc=com.
When SASE client login fails under user-certificate authentication, troubleshooting steps check whether the certificate’s CN – typically a User Principal Name or display name – matches the username the user is authenticating as; a mismatch there is a documented cause of failure.
Frequently asked questions
What is the difference between a Common Name and a Subject Alternative Name?
The Common Name is a single subject field historically used for hostname matching; the Subject Alternative Name (SAN) is a certificate extension that can list multiple hostnames, IP addresses, or identities. Modern browsers and TLS libraries validate against SAN entries, treating CN as informational rather than authoritative.
Why do modern browsers no longer trust the Common Name for hostname validation?
Security research showed CN-only matching was easy to spoof and inconsistent across implementations. The CA/Browser Forum and major browser vendors deprecated CN-based hostname checking in favor of the SAN extension, which a CA signs explicitly for every hostname a certificate covers.
Is a Common Name the same as a Distinguished Name?
No. A Distinguished Name (DN) is the full hierarchical identifier for a certificate subject or directory entry, built from multiple attributes. Common Name is just one of those attributes – usually the most specific one – combined with Organization, Locality, and others to form the complete DN.
What happens if a certificate’s Common Name doesn’t match the server hostname?
Clients that still check CN, or fall back to it when no SAN is present, display a certificate-trust warning or refuse the connection. On Versa Director, a CN that doesn’t exactly match the node’s hostname can prevent a certificate from installing or validating correctly.
How does Versa use the Common Name in device or user certificate authentication?
Versa’s SSE Gateway lets administrators select CN as the “Username Identifying Field in Certificate” for device- or user-certificate authentication profiles, so the value in the presented certificate’s CN is matched against the LDAP or SAML username before access is granted.
More on Common Name
If you want to learn more, these are sources we trust.
| IETF RFC 5280 | NIST CSRC Glossary |
|---|---|
| The IETF profile that defines X.509 certificate and CRL fields, including the subject Distinguished Name that carries CN. | NIST’s Computer Security Resource Center glossary of cryptography and PKI terminology, including certificate subject fields. |
Related terms
If you’re reading about Common Name, these are worth looking at next.
| Certificate Signing Request | Distinguished Name | Subject Alternative Name |
|---|---|---|
| The file, containing a public key and subject fields such as CN, that is submitted to a CA to obtain a signed certificate. | The full hierarchical identifier for a certificate subject or LDAP entry, built from attributes that include CN. | The certificate extension that lists valid hostnames and IPs; it supersedes CN for modern TLS hostname validation. |