Java MTLS Subject 和 Issuer 顺序

Question

我们正在升级我们自己和合作伙伴之间的连接，他们要求我们升级到 MTLS。我一直在调试低级 java，

javax.net.debug=all我可以看到握手成功。然而，合作伙伴对主题和发行人字段进行了完整的字符串匹配，并与他们数据库中的某些字段进行了比较。

我用过下面的，

   if (cert instanceof X509Certificate) {
        X509Certificate x509cert = (X509Certificate) cert;

        // Get subject
        Principal principal = x509cert.getSubjectDN();
        String subjectDn = principal.getName();
        logger.error(subjectDn);
        // Get issuer
        principal = x509cert.getIssuerDN();
        String issuerDn = principal.getName();
        logger.error(issuerDn);
    }

转储 java 的值。有趣的是，openssl 以与 java 报告完全不同的顺序报告它们。

我现在一直在 Wireshark 中挖掘，我可以从那个级别看到握手，但是，它似乎将名称转换为 id-at-commonName，pkcs-9 -at-emailAddress 据我所知。

有什么方法可以知道实际发送的是什么？

Answer 1

没有协议(protocol) MTLS，但听起来您关心的是 TLS 中的客户端身份验证，也称为相互身份验证，它与服务器身份验证一样通常使用 X.509 类型(更准确地说，PKIX)证书。

背景:X.509/PKIX 证书使用 X.500/501 Distinguished Name structure 标识主题和颁发者(有时在某些扩展中还有其他事物/实体)也称为 X500Name、X501Name 或简称为 Name。这种结构在 ASN.1 中定义为 RelativeDistinguishedName 项的序列(有序)，每个项都是正式的一组(无序)属性类型和值对(序列)，尽管实际上 RDN 集合几乎总是单例，所以名称实际上是属性类型和值的序列。此名称格式旨在用于全局、分布式、分层的“目录”网络，而不是类似 DNS，除了(因为 CCITT-now-ITU-T 是一个政府机构组织)主要 Root 于在基于国家/地区的国家目录中，而不是像 .com .org .edu .gov .mil .net 这样的功能性或“通用”目录中，并且 X.509 证书基本上被设计为从中导出数据可离线使用的目录网络。实际上，真正的 X.500 目录根本没有被使用，甚至像 LDAP(轻量级目录访问协议(protocol))这样的协议(protocol)也没有被广泛使用，除了 Microsoft Windows“域”(Active Directory)，但是 X.509 证书包括其中使用的名称格式广泛用于 SSL-now-TLS、S/MIME 和许多其他应用程序。

DN 的常规文本或外部形式是一系列 attr=value 项，其中 attr 通常缩写，例如C 代表国家，ST 代表 StateOrProvince，CN 代表 CommonName 等。Java 使用 RFC 1485、1779、2253 和 4514 定义的标准化形式(具有小的更改/改进)，其中项目用逗号分隔并以 反向给出order 即从最后(最低级别)到第一个(最高级别通常是根)，类似于 DNS。例如 Java 显示 www.duckduckgo.com 当前使用的证书的主题作为

CN=*.duckduckgo.com, O="Duck Duck Go, Inc.", L=Paoli, ST=Pennsylvania, C=US

OpenSSL 传统上默认使用一种格式，在每个项目之前使用斜杠(而不是用逗号分隔)，并且还按向前顺序

/C=US/ST=Pennsylvania/L=Paoli/O=Duck Duck Go, Inc./CN=*.duckduckgo.com

但是 1.1.0 向上更改了默认使用带前向顺序的逗号分隔符

C = US, ST = Pennsylvania, L = Paoli, O = "Duck Duck Go, Inc.", CN = *.duckduckgo.com 

一些OpenSSL命令行操作，如x509，支持其他显示格式；请参阅“名称选项”下的手册页。特别是 x509 -nameopt oneline,dn_rev 给出了与 Java 几乎相同的格式:

CN = *.duckduckgo.com, O = "Duck Duck Go, Inc.", L = Paoli, ST = Pennsylvania, C = US

如果您只查看传输证书的摘要(在 TLS 中)，Wireshark 会显示具有全名的属性=值对，而不是属性的缩写，与 RFC 和 Java 的顺序相反:

但是如果您单击加号框展开几个级别，您可以分别看到每个属性项的结构，按正向顺序:

正是因为在显示格式上存在并且一直存在多种变体，所以将 DN 作为字符串进行比较并不是一个好主意。如果您需要将其作为字符串存储在例如一个数据库，更好的方法是从字符串重建结构化形式——使用一致的顺序、缩写等约定——并比较结构化对象。如果您阅读 javadoc 并看到 X509Certificate.getIssuerDN()，这会变得更容易一些。并且类似地 .getSubjectDN() 被“诋毁”(显然是为了“弃用”)并从 Java 1.4 开始被 .getIssuerX500Principal() 和 .getSubjectX500Principal( ) 使用文档化的 API 类(而不是不透明的内部类)javax.security.auth.x500.X500Principal使用记录在案的 .equals() 操作。