我们有一个Microsoft Active Directory域，其中包含大量的域控制器（DC），这些域控制器是使用LDAP设置的。这些都是使用LDAPS设置的，并通过模板使用证书服务来设置证书的域名（即test.corp），该域名在LDAPS服务器要使用的使用者备用名称（SAN）中。
由于这些是DC，因此将在每个系统的池中设置DNS，以循环方式响应对test.corp的请求。
这些DC中的每个DC在“本地计算机\个人证书存储”中都有多个模板和多个证书。
使用域名test.corp发出LDAPS请求时，在使用nodejs模块ldapjs进行测试时，我们注意到少数服务器失败，并显示以下消息：
错误[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标准？
答案 0 :(得分：0)
假定LDP将针对客户端存储验证SSL。
也就是说，鉴于它和ADSI编辑通常用于配置或修复损坏的配置，因此它和ADSI编辑都没有执行该标准的这一部分，我并不感到惊讶。开箱即用且没有证书服务，他们在LDAPS上使用自签名证书。我会下注80％的DC永远不会获得LDAP的适当证书。如果他们强制执行，大多数将无法连接。更好的设计决定是取消验证。
我使用类似的openssl命令来验证自己的系统。我认为，即使LDP验证证书，它也优于LDP。为了节省您的精力，我建议使用openssl命令的以下变体：
echo | openssl s_client -connect .test.corp:636 2>/dev/null | openssl x509 -noout -dates -issuer -subject -text
那应该省去了输出到文件和使用其他工具读取文件的麻烦。
由于您所描述的确切原因，我发现AD上的LDAPS令人非常痛苦。它似乎只是拿起它可以找到的第一个有效证书。如果您已经将其添加到AD DS个人存储中，那么除了从DCs计算机存储中删除一些Tother证书之外，我不确定其他建议。
答案 1 :(得分：0)
RFC6125特别声明它不会取代现有的RFC。 LDAP证书处理在RFC4513中定义。除此之外，RFC6125还有很多缺陷。另请参见https://bugzilla.redhat.com/show_bug.cgi?id=1740070#c26