RelativeDistinguishedName in the RDNSequence (according to SectionĢ.2), starting with the last element of the sequence and moving For some reason, the string representation was defined to list the name elements in reverse order: Otherwise, the output consists of the string encodings of each Making the issue more confused is RFC 4514 (that replaces the older RFC 2253): this is the standard representation of a DN into a string, to be used in LDAP context. To see the order of name elements in a subjectDN, you can use openssl asn1parse as indicated by in his answer. The SSL client (Web browser) will (at most) extract the Common Name element, regardless of where it appears in the sequence, and disregard all other elements. The issuerDN of a certificate must be identical to the subjectDN of the certificate of the CA that issued it (and in particular must have the elements in the same order), but beyond that there is no order to follow. When using certificates for SSL servers, the order of name elements in a distinguished name does not bear any specific meaning. In fact, even in Windows + Active Directory (which is very keen on using LDAP), when a certificate is mapped to an account, the account is usually located with the UPN, which is a Microsoft-specific type of name located not in the subjectDN, but in a Subject Alt Name extension the subjectDN is then really used only for display purposes (the Common Name element of the subjectDN is shown to the human user). For some usages, you may want to mind the order of fields in the subjectDN if the software that uses the certificate will really connect to some LDAP server and use the subjectDN to get more data about the certificate owner. Shrunk, diluted, local versions of the Directory do exist: they are called LDAP servers (or "Active Directory" in the Windows world). The Directory can be envisioned as a world-wide structure that references everything its main problem is that it never actually existed. The ordering of elements in a distinguished name relates to why such names were defined in the first place: as an indexing path into the Directory. It is quite rare to have several name elements in the same set (I have seen it done to put the Common Name, First Name and Last Name together, as three elements with the same level). Its definition really is a SEQUENCE of SET of name elements, so it is an ordered sequence of unordered sets of elements. In the subjectDN field of a certificate, there is the certificate owner distinguished name, which is nominally ordered.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |