ssl Java MTLS主体和颁发者顺序

Question

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

javax.net.debug=all 我可以看出握手是成功的。但是，合作伙伴会对Subject和Issuer字段进行完整的字符串匹配，并与数据库中的其他字段进行比较

我使用了以下方法

   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

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

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

DN的传统文本或外部形式是一系列attr=值项，其中attr通常缩写，例如C代表国家，ST代表州或省，CN代表CommonName等。Java使用RFCs 1485、1779和，2253和4514，其中项目由逗号分隔，并以相反的顺序给出，即从最后一个（最低级别）到第一个（最高级别通常为根），类似于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

Wireshark如果您只查看传输的证书（在TLS中）的摘要，则会显示属性=值对，并带有全名，而不是属性的缩写，其顺序与RFCs和Java相反：

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

正是因为显示格式有很多变化，所以将DNs作为字符串进行比较不是一个好主意。如果需要将其作为字符串存储在数据库中，更好的方法是使用顺序、缩写等一致约定从字符串重建结构化形式，并比较结构化对象。如果您阅读javadoc并看到^{}和类似的.getSubjectDN()被“贬损”（显然是为了“弃用”）并从Java 1.4起被.getIssuerX500Principal()和.getSubjectX500Principal()取代，它们使用有文档的API类（而不是不透明的内部类）^{a6和有文档的.equals()操作