Is there an order to respect in subjectName field when creating a x509 certificate with OpenSSL command? In other words, what are all possibilities of displaying subjectName of x509 certificate in OpenSSL?
subjectDN field of a certificate, there is the certificate owner distinguished name, which is nominally ordered. Its definition really is a
SET of name elements, so it is an ordered sequence of unordered sets of elements. 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).
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. The Directory can be envisioned as a world-wide structure that references everything; its main problem is that it never actually existed. Shrunk, diluted, local versions of the Directory do exist: they are called LDAP servers (or "Active Directory" in the Windows world). 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. This is a rare case. 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).
When using certificates for SSL servers, the order of name elements in a distinguished name does not bear any specific meaning. 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. 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.
To see the order of name elements in a
subjectDN, you can use
openssl asn1parse as indicated by @StackzOfZtuff in his answer. 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. 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 RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first.
Nevertheless, when using
openssl x509 -text -noout to display the contents of a certificate, OpenSSL will show the
issuerDN as strings in a format which is very close to RFC 4514, except that it follows the order of appearance of the name elements in the encoded certificate, not the "reverse order" mandated by RFC 4514.
"Names" may also appear in the Subject Alternative Names extension. That extension is defined to contain a
GeneralName, i.e. it is technically ordered. However, nothing in X.509 attaches any semantic to the order of names; in fact, this extension is defined to use a
SEQUENCE OF and not a
SET OF mostly because encoding a
SET OF with DER rules is more expensive (you have to sort the names lexicographically). The order in which the various names in a SAN extension appears has no influence whatsoever on the validity of a certificate, and should not change anything in application behaviour.
Of course, any given software may fail to do things correctly. In a SSL context, it is common for several names of type
dNSName to appear in a SAN extension: the browser will scan all the names until it either finds a name that matches the expected server name (as it appears in the URL), or runs out of names, whichever comes first; this behaviour, implicitly, does not ultimately depends on the order of names.
You can display Subject Alternative Names (SANs) with OpenSSL like this:
(I'm using the Facebook.com cert as an example.)
$ openssl x509 -in facebook-cert.pem.cer -noout -text | grep 'Subject Alternative Name' -A1
X509v3 Subject Alternative Name: DNS:*.facebook.com, DNS:facebook.com, DNS:*.fb.com, DNS:fb.com, DNS:*.fbsbx.com, DNS:*.fbcdn.net, DNS:*.xx.fbcdn.net, DNS:*.xy.fbcdn.net, DNS:*.xz.fbcdn.net, DNS:*.m.facebook.com, DNS:*.messenger.com, DNS:messenger.com
$ openssl asn1parse -in facebook-cert.pem.cer -i -dump | nl | sed '74,85p' -n
74 452:d=5 hl=3 l= 175 prim: OCTET STRING 75 0000 - 30 81 ac 82 0e 2a 2e 66-61 63 65 62 6f 6f 6b 2e 0....*.facebook. 76 0010 - 63 6f 6d 82 0c 66 61 63-65 62 6f 6f 6b 2e 63 6f com..facebook.co 77 0020 - 6d 82 08 2a 2e 66 62 2e-63 6f 6d 82 06 66 62 2e m..*.fb.com..fb. 78 0030 - 63 6f 6d 82 0b 2a 2e 66-62 73 62 78 2e 63 6f 6d com..*.fbsbx.com 79 0040 - 82 0b 2a 2e 66 62 63 64-6e 2e 6e 65 74 82 0e 2a ..*.fbcdn.net..* 80 0050 - 2e 78 78 2e 66 62 63 64-6e 2e 6e 65 74 82 0e 2a .xx.fbcdn.net..* 81 0060 - 2e 78 79 2e 66 62 63 64-6e 2e 6e 65 74 82 0e 2a .xy.fbcdn.net..* 82 0070 - 2e 78 7a 2e 66 62 63 64-6e 2e 6e 65 74 82 10 2a .xz.fbcdn.net..* 83 0080 - 2e 6d 2e 66 61 63 65 62-6f 6f 6b 2e 63 6f 6d 82 .m.facebook.com. 84 0090 - 0f 2a 2e 6d 65 73 73 65-6e 67 65 72 2e 63 6f 6d .*.messenger.com 85 00a0 - 82 0d 6d 65 73 73 65 6e-67 65 72 2e 63 6f 6d ..messenger.com