我們正在升級我們自己和合作伙伴之間的連接，他們要求我們升級到 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有什么辦法可以知道實際發送的內容是什么？
1 回答
達令說
TA貢獻1821條經驗 獲得超6個贊
沒有協議 MTLS，但聽起來您關心的是 TLS 中的客戶端身份驗證（也稱為相互身份驗證），它與服務器身份驗證一樣通常使用 X.509 類型（更準確地說，PKIX）證書。
背景：X.509/PKIX 證書使用X.500/501 可分辨名稱結構（也稱為 X500Name、X501Name 或簡稱為名稱）來標識主體和頒發者（有時還標識某些擴展中的其他事物/實體） 。該結構在 ASN.1 中被定義為relativedistinguishedname項的SEQUENCE（有序），其中每個項正式是屬性類型和值對（SEQUENCE）的SET（無序），盡管實際上RDN SET幾乎總是單例，因此名稱實際上是屬性類型和值的序列。這種名稱格式旨在用于全球、分布式、分層的“目錄”網絡，類似于DNS除了（因為 CCITT-現在的 ITU-T 是一個政府機構組織）主要植根于基于國家/地區的國家目錄，而不是像 和 X.509 證書這樣的功能性或“通用”目錄，X.509 證書基本上被設計為從該目錄導出.com .org .edu .gov .mil .net數據可離線使用的目錄網絡。實際上，真正的 X.500 目錄根本不被使用，甚至除了 Microsoft Windows“域”（Active Directory）之外，甚至像 LDAP（輕量級目錄訪問協議）這樣的協議也沒有被太多使用，但 X.509 證書包括其中使用的名稱格式廣泛用于 SSL-now-TLS、S/MIME 和許多其他應用程序。
DN 的常規文本或外部形式是一系列 attr=value 項，其中 attr 通常是縮寫，例如 C 代表國家/地區、ST 代表州或省、CN 代表 CommonName 等。Java 使用定義的標準化形式（有一些小的變化） /improvements）由 RFC 1485、1779、2253 和 4514 制定，其中項目以逗號分隔并按相反順序給出，即從最后一個（最低級別）到第一個（最高級別通常為根），類似于 DNS。
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 將顯示帶有全名的 attribute=value 對，而不是屬性的縮寫，與 RFC 和 Java 一樣，按相反的順序：
但是，如果單擊加號框展開幾個級別，您可以按正向順序分別查看每個屬性項的結構：
正是因為顯示格式存在并且已經有許多變化，所以將 DN 作為字符串進行比較并不是一個好主意。如果您需要將其作為字符串存儲在例如數據庫中，更好的方法是從字符串重建結構化形式——使用關于順序、縮寫等的一致約定——并比較結構化對象。如果您閱讀 javadoc 并看到 和X509Certificate.getIssuerDN()類似地.getSubjectDN()被“詆毀”（顯然是為了“棄用”）并且自 Java 1.4 以來被.getIssuerX500Principal()和取代.getSubjectX500Principal()，它使用記錄的 API 類（而不是不透明的內部類），那么這會變得更容易一些javax.security.auth.x500.X500Principal并有記錄的.equals()操作。
添加回答
舉報
0/150
提交
取消