The Distinguished Name (DN) for an entity should be bind to some acceptable or existing user ID. Check also "Understanding OSI names".
The structure of your DN also defines your DIT (Directory Information Tree) in LDAP directory.
Assign a user name to common name component. ie: cn=FirstnameLastname
The others, optional, parts of the DN are
- Either a set of Organisation name and Country code_ ie: o=My_Organisation, c=US
- Either a set of many Domain Components ie: "dc=example,dc=com" standing for example.com
- Optionally you may have organisation units ie: ou=Finance or ou=people or ou=services
- Optionally you may have additional cn as used by Microsoft naming scheme (cn=MyName,cn=Users,..)
Finally you obtain your subject value called a Distinguished Name abreviated as DN
- example 1: cn=FirstnameLastname
- example 2: cn=FirstnameLastname,o=My_Organisation,c=US
- example 3: cn=FirstnameLastname,dc=example,dc=com
- example 4: cn=FirstnameLastname,ou=people,dc=example,dc=com
- example 4: cn=FirstnameLastname,uid=My_login,ou=people,dc=example,dc=com
This is the OSI naming scheme, also used in LDAP directories (like Microsoft AD) and X400 mail systems. If your certificate is stored in an LDAP directory, it could be stored in the same DIT (Directory Information Tree) as the one of it's Distinguished name, or it could be stored under another DIT.
openOSI stores the public signed certificates this way for class 1
- DIT is "ou=VirtualPeople,dc=openosi,dc=org"
- ObjectClass=top, ObjectClass=Person, ObjectClass=organizationalPerson, ObjectClass=InetOrgPerson
- cn=FirstnameLastname - The cn value of certificate subject
- sn=Lastname (default to cn value)
- mail=My.Name@example.com (default to verified e-mail address of the request)
- userCertificate="Binary form of your public certificate"
That is, if requesting an openOSI signed certificate, there is no need to fill something else than the common name as your user name, because openOSI will not certify additional information for its class 1 certification. Others parts like "o=My_Organisation, c=US" will be removed from the certificate unless you require a class 2 certificate (not available for now and subject to peer agreement).
| Uniqueness of cn component in DN
Most of the time it is useful to have a unique value in that field, although, unique is always in a "local" context. The certificate subject alternative name refine (or replace) the subject (i.e: with e-mail address), but some authentication mechanisms like SASL EXTERNAL only uses the subject DN.
It is possible to put an e-mail address in the cn value, but many applications will fail (i.e: Liferay portal). Therefore, avoid this solution because you may have unpredictable situations with a given application.
Finaly, I recommend, when possible, to insert an "uid" component in the DN, which may look like this;
Where "uid" in example, MAY be build like follows:
Last 4 digit of social security number: 1234 (or whatever algorytm)
This uid is supposed to be unique in the scope of a given directory (MUST be unique if you enforce controlled uid delivery). The email address remains the only worldwide unique id, if present in the subject alternative name. Note that a person MAY have multiple virtual identities, one for each of its email addresses. This is defaults for openosi.org online certification authority. The pre-registration for the certificate retrieval enforces uniqueness of the UID in the openosi directory
You may also put this UID value in the CN.
If you choose to generate yourself a certificate request (CSR) using keyman or any other tools including Linux based tools like openssl, it could be mandatory to fill all attributes like country, organisation, organisation unit, location .... We recommend you enter as few information as possible, entering blanks where appropriate, because a certification authority is supposed to verify all the requested attributes. This is not necessary for most authentications and is costly (however the CA could silently drop some of your unverified attributes).