Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
With regard to these three items
What is the significance of the Common Name CN with regard to the a VPN? Does the Certificate Authority have to have the CN of the Gateway Cert? Any other information about the CN with relation to VPNs would be great.
How are they used for authenticity of the certs?
I'm using StrongSwan v5.x if it matters.
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:
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.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 "security.stackexchange.com").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.
The meaning depends on the particular implementation and installation. Typically it identifies a given VPN consumer; be that a user, host, or configuration set.
Usually the signature path determines whether the certificate is permissible, while the CN determines which permissible certificate it is.
