4

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?

  • Can you confirm if you mean ordering of the DN (distinguished name) components, or the subjectName in a CSR, or possibly the ordering of the subjectAlternativeName elements? – mr.spuratic Jul 15 '15 at 11:31
  • @Vilican I'm not an expert in cryptography, so I don't know what is the difference between these elements. But I'm looking for the subjectName. – Hakim Jul 15 '15 at 13:12
  • @HakimBenyoucef - I only fixed the grammar in the question. I do not know what "elements" are you talking about. – Vilican Jul 15 '15 at 15:16
  • I talk about the three elements that you have mentioned above which are: DN, subjectName and subjectAlternativeName. – Hakim Jul 15 '15 at 15:34
3

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.

  • For creating with OpenSSL (as first asked, rather than just displaying) if you use commandline openssl ca and you don't specify -preserveDN or have configured preserve=yes the subject DN in the cert is (re)ordered from the CSR according to the fields in the configured 'policy' section. In the (upstream) distributed config file, the DN fields in a CSR and the DN fields in the two CA policies are the same top-down order (C,ST,L,O,OU,CN,email) but these can be editted or overridden. – dave_thompson_085 Jul 18 '15 at 8:45
3

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
  • dumpasn1 will re-parse the OCTET STRING for you, you need a (seekable file) DER form though: openssl x509 -in facebook-cert.pem.cer -outform DER -out facebook.der; dumpasn1 -tilda facebook.der – mr.spuratic Jul 15 '15 at 11:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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