Historically, the Distinguished Names in certificates (specified by X.500) were meant to designate an entity within the Directory, which is the global, worldwide, tree-structured repository for identity management data. The Directory can be thought of as a giant LDAP server with delegation to sub-servers, in a way somewhat similar to the DNS. In reality, though, the Directory never existed, and LDAP is a practical subset of the Directory Access Protocol. Still, the naming principles remained in force.
A DN is an ordered sequence of typed named elements, which, for the Directory, should come in the order: Country, State-or-Province, Organization, Organizational Unit (possibly several), and then Common Name. X.500 is rather open-ended and other orderings are possible (and the format supports putting several name elements at the same level), but the rough idea is that the Common Name is the lowest level of the hierarchy. Thus, the Common Name for an entity, any entity, is the most precise naming element.
Since the Directory does not actually exist, you can put just about anything you want in the Common Name, subject to the following restrictions:
- Encoding must comply to the X.509 ASN.1 specification: the Common Name is limited to 64 characters (64 code points if using
UTF8String, as you should, per the standard).
IssuerDN of a certificate must be equal to the
SubjectDN of its issuer. Equality rules are theoretically case-insensitive, but the rules can be complex to implement in a full Unicode world, so you'd better make sure that you have byte-to-byte equality, which will work properly everywhere.
- The certificate of a SSL server must contain the server name as expected by the client (if using HTTPS, this name will be the one in the URL). This is specified in RFC 2818. The
Subject Alt Name extension is normally used, but the Common Name serves as backup in case this extension is missing. Since SSL client implementations have not always strictly adhered to the relevant RFC, it is best, to avoid issues, if the SSL server's certificate contains the server DNS name as Common Name (fully qualified name, as in "
- When a certificate, or an identity extracted from a certificate, is "shown" to a human user, the Common Name will figure proeminently. For instance, if using smart card logon on a Windows system, then the logon screen will show the Common Name in big letters when the smart card is inserted. So you'd better make the Common Name meaningful for the common man.
In the case of a VPN server, the certificate from the client is for the sole usage of the server. The server interprets the certificate contents, including the Subject DN and its Common Name, in any ways as it sees fit, including ignoring it altogether. For instance, in a Microsoft IIS + Active Directory context, when a client is authenticated through a certificate, the server will use the User Principal Name as found in the
Subject Alt Name extension, under a Microsoft-specific OID. The Common Name might be displayed to the human user, if there is a human user (e.g. as part of a certificate selection popup), but will be ignored for authentication purposes.
Generically, your client's certificates will have to contain whatever is required by the authentication system that the VPN server uses, and since that is highly configurable, this depends a lot on the local context. For instance, the VPN server may delegate authentication to a RADIUS server, in which case the certificate characteristics (including the Common Name) will be described by the RADIUS server documentation; for the VPN server, this would be just an opaque blob.