LDAPS Microsoft Active Directory 多證書 RFC6125
我們有一個 Microsoft Active Directory 域，其中包含大量使用 LDAP 設置的域控制器 (DC)。這些都是使用 LDAPS 設置的，並通過模板使用證書服務來設置證書，其中包含主題備用名稱 (SAN) 中的域名（即 test.corp），以供 LDAPS 伺服器提供服務。
由於這些是 DC，因此在每個系統的池中設置 DNS，以循環方式響應對 test.corp 的請求。
這些 DC 中的每一個在本地電腦\個人證書儲存中都有多個模板和多個證書。
在測試時，使用 nodejs 模組 ldapjs 在使用域名 test.corp 發出 LDAPS 請求時，我們注意到少數伺服器失敗並顯示以下消息：
錯誤
$$ ERR_TLS_CERT_ALTNAME_INVALID $$：主機名/IP 與證書的替代名稱不匹配：主機：test.corp。不在證書的 altnames 中：othername:, DNS:.test.corp
在我們調查的過程中，我們發現這些少數 LDAPS 伺服器提供的證書不正確。我們使用以下命令確定了這一點
openssl s_client -connect .test.corp:636
如果您將輸出的證書部分放入文件中並使用證書管理器或 certutil 等工具讀取文件，您會發現證書不正確。（它沒有域“test.corp”SAN）。我們還通過比較序列號來驗證這一點
正如我們調查的那樣，由於我們的 DC 在本地電腦\個人證書儲存中具有多個證書，因此我們遇到了以下文章：
它建議將證書從本地電腦\個人證書儲存到 Active Directory 域服務\個人儲存。我們遵循了概述的步驟，但我們發現了相同的結果。
經過進一步調查，建議使用名為 ldp 或 adsiedit 的工具。然後，我們繼續使用這些工具並欺騙了我們正在執行測試的本地電腦的主機文件，將域 (test.corp) 指向給我們帶來麻煩的 DC 之一的 ip。重新啟動以清除所有記憶體後，我們測試了“ldp”和“adsiedit”工具以連接到 test.corp。這些系統沒有報告任何錯誤。
我們發現這很奇怪，然後我們執行 openssl 命令查看它從同一系統提供的證書，我們發現它仍在提供不正確的證書。
經過進一步研究，選擇 SSL 複選框時的“ldp”和“adsiedit”工具似乎不符合 RFC6125，特別是 B.3
，它基本上說明證書的身份必須與請求的身份匹配，否則握手將失敗。此身份驗證是通過使用證書公用名 (CN) 或 SAN 完成的。
基於此，“ldp”和“adsiedit”工具似乎不符合 RFC6125 標準。
綜上所述，我們首先需要修復少數提供正確證書的域控制器。我們對建議持開放態度，因為過去幾個月我們一直在解決這個問題。其次，有沒有辦法讓有問題的 MS 工具符合 RFC6125 標準？
注意：如果我把它發佈到了不正確的板上（即堆棧溢出），請告訴我，我將刪除並重新發佈到正確的位置。
RFC6125 特別聲明它不會取代現有的 RFC。LDAP 證書處理在 RFC4513 中定義。除此之外，RFC6125 存在重大缺陷。另請參閱https://bugzilla.redhat.com/show_bug.cgi?id=1740070#c26