在subjectDN证书字段中，有证书所有者专有名称，名义上是有序的。它的定义实际上是一个SEQUENCEof SETname元素，所以它是一个有序序列的无序元素集合。在同一个集合中有多个名称元素是非常罕见的（我已经看到将通用名称、名字和姓氏放在一起，作为具有相同级别的三个元素）。

可分辨名称中元素的顺序与为什么首先定义此类名称有关：作为目录的索引路径。可以将目录设想为引用所有内容的全球结构；它的主要问题是它从未真正存在过。目录的缩小、稀释、本地版本确实存在：它们被称为 LDAP 服务器（或 Windows 世界中的“活动目录”）。对于某些用法，subjectDN如果使用证书的软件真的会连接到某个 LDAP 服务器并使用subjectDN获取有关证书所有者的更多数据。这是一种罕见的情况。事实上，即使在 Windows + Active Directory（非常热衷于使用 LDAP）中，当一个证书映射到一个帐户时，该帐户通常都位于UPN中，这是一种 Microsoft 特定类型的名称，不位于subjectDN，但在主题替代名称扩展中；subjectDN然后实际上仅用于显示目的（subjectDN向人类用户显示的 Common Name 元素）。

在为 SSL 服务器使用证书时，专有名称中名称元素的顺序不具有任何特定含义。证书的issuerDN必须与subjectDN颁发它的 CA 的证书相同（特别是必须具有相同顺序的元素），但除此之外没有可遵循的顺序。SSL 客户端（Web 浏览器）将（最多）提取 Common Name 元素，而不管它出现在序列中的什么位置，而忽略所有其他元素。

要查看 a 中名称元素的顺序subjectDN，您可以openssl asn1parse按照@StackzOfZtuff 在他的回答中的指示使用。使问题更加混乱的是RFC 4514（它取代了旧的 RFC 2253）：这是 DN 到字符串的标准表示，用于 LDAP 上下文。出于某种原因，字符串表示被定义为以相反的顺序列出名称元素：

   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.

然而，当openssl x509 -text -noout用于显示证书的内容时，OpenSSL 将以非常接近 RFC 4514 的格式将subjectDN和显示为字符串，除了它遵循编码证书中名称元素的出现顺序，而不是 "逆序”由 RFC 4514 规定。issuerDN

“名称”也可能出现在主题备用名称扩展中。该扩展被定义为包含 a SEQUENCEof GeneralName，即它在技术上是有序的。然而，X.509 中没有任何语义附加到名称的顺序上。事实上，这个扩展被定义为使用 aSEQUENCE OF而不是 aSET OF主要是因为使用 DER 规则对 a 进行编码SET OF更昂贵（您必须按字典顺序对名称进行排序）。SAN 扩展中各种名称出现的顺序对证书的有效性没有任何影响，也不应该改变应用程序的任何行为。

当然，任何给定的软件都可能无法正确执行操作。在 SSL 上下文中，dNSName在 SAN 扩展中出现多个类型名称是很常见的：浏览器将扫描所有名称，直到找到与预期服务器名称匹配的名称（如它出现在 URL 中），或者运行没有名字，以先到者为准；隐含地，这种行为最终并不取决于名称的顺序。

您可以使用 OpenSSL 显示主题备用名称 (SAN)，如下所示：（
我使用 Facebook.com 证书作为示例。）

使用x509子命令：

$ 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

使用asn1parse子命令：

$ 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