我们有一个 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。不在证书的替代名称中：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 复选框和“adsiedit”工具时的“ldp”不符合 RFC6125，特别是 B.3
，其基本含义是证书的身份必须与请求的身份相匹配，否则握手将失败。此身份验证是通过使用证书通用名称 (CN) 或 SAN 来完成的。
基于此，工具“ldp”和“adsiedit”似乎不符合 RFC6125 标准。
总而言之，我们需要首先修复提供正确证书的少数域控制器。我们愿意听取建议，因为我们过去几个月一直在解决这个问题。其次，有没有办法让有问题的 MS 工具符合 RFC6125 标准？
注意：如果我将其发布到了错误的板上（即 stack overflow），请告诉我，我会删除并重新发布到正确的位置。
答案1
RFC6125 明确指出，它不会取代现有的 RFC。LDAP 证书处理在 RFC4513 中定义。除此之外，RFC6125 存在重大缺陷。另请参阅https://bugzilla.redhat.com/show_bug.cgi?id=1740070#c26