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 在本地计算机\个人证书存储中具有多个证书，因此我们遇到了以下文章：

https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

它建议将证书从本地计算机\个人证书存储到 Active Directory 域服务\个人存储。我们遵循了概述的步骤，但我们发现了相同的结果。

经过进一步调查，建议使用名为 ldp 或 adsiedit 的工具。然后，我们继续使用这些工具并欺骗了我们正在执行测试的本地计算机的主机文件，将域 (test.corp) 指向给我们带来麻烦的 DC 之一的 ip。重新启动以清除所有缓存后，我们测试了“ldp”和“adsiedit”工具以连接到 test.corp。这些系统没有报告任何错误。

我们发现这很奇怪，然后我们运行 openssl 命令查看它从同一系统提供的证书，我们发现它仍在提供不正确的证书。

经过进一步研究，选择 SSL 复选框时的“ldp”和“adsiedit”工具似乎不符合 RFC6125，特别是 B.3

https://www.rfc-editor.org/rfc/rfc6125#appendix-B.3

，它基本上说明证书的身份必须与请求的身份匹配，否则握手将失败。此身份验证是通过使用证书公用名 (CN) 或 SAN 完成的。

基于此，“ldp”和“adsiedit”工具似乎不符合 RFC6125 标准。

综上所述，我们首先需要修复少数提供正确证书的域控制器。我们对建议持开放态度，因为过去几个月我们一直在解决这个问题。其次，有没有办法让有问题的 MS 工具符合 RFC6125 标准？

注意：如果我把它发布到了不正确的板上（即堆栈溢出），请告诉我，我将删除并重新发布到正确的位置。