OpenSSL x509: Is there an order in subjectName fields?

Question

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?

Answer 1

In the subjectDN field of a certificate, there is the certificate owner distinguished name, which is nominally ordered. Its definition really is a SEQUENCE of 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 subjectDN and 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 SEQUENCE of 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.

Answer 2

You can display Subject Alternative Names (SANs) with OpenSSL like this:
(I'm using the Facebook.com cert as an example.)

Using the x509 subcommand:

$ 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

Using the asn1parse subcommand:

$ 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