Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

With regard to these three items

  1. Certificate Authorities (CA)
  2. Gateway certificates
  3. End-point Certificates (client-cert)

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.

share|improve this question
add comment

2 Answers

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).
  • The 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 "security.stackexchange.com").
  • 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.

share|improve this answer
    
Can you explain what IssuerDN and SubjectDN are in the above example. the question arises out of a concern that the end-point has to have the same DN of the Gateway? Is that true? Does the client have to have the same DN as the Certificate Authority? Who has the logic that checks the two? The client or the gateway? –  Evan Carroll Aug 5 '13 at 1:38
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.