LDAPS Microsoft Active Directory 多个证书 RFC6125
LDAPS Microsoft Active Directory Multiple Certificates RFC6125
我们有一个 Microsoft Active Directory 域，其中包含大量使用 LDAP 设置的域控制器 (DC)。这些都是使用 LDAPS 设置的，并通过模板使用证书服务在主题备用名称 (SAN) 中设置带有域名（即 test.corp）的证书，供 LDAPS 服务器使用。
由于这些是 DC，因此在每个系统的池中设置了 DNS，以循环方式响应对 test.corp 的请求。
这些 DC 中的每一个在本地 Computer\Personal 证书存储中都有多个模板和多个证书。
经过测试，使用 nodejs 模块，ldapjs 在使用域名发出 LDAPS 请求时，test.corp 我们注意到少数服务器失败并显示以下消息：
Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match
certificate's altnames: Host: test.corp. is not in the cert's
altnames: othername:, DNS:.test.corp
在调查过程中，我们发现这些少数 LDAPS 服务器提供的证书不正确。我们使用以下命令确定了这一点
openssl s_client -connect .test.corp:636
如果您将输出的证书部分放入文件中，然后使用证书管理器或 certutil 等工具读取该文件，您会发现证书不正确。 （它没有域“test.corp”SAN）。我们还通过比较序列号
验证了这一点
根据我们的调查，由于我们的 DC 在本地 Computer\Personal 证书存储中有多个证书，我们发现了以下文章：
它建议将证书从本地 computer\Personal 证书存储区放入 Active Directory 域 Service\Personal 存储区。我们按照概述的步骤进行操作，但发现了相同的结果。
经过进一步调查，建议使用名为 ldp 或 adsiedit 的工具。然后，我们继续使用这些工具并欺骗我们从中进行测试的本地机器的主机文件，将域 (test.corp) 指向给我们带来麻烦的 DC 之一的 ip。重新启动以清除任何缓存后，我们测试了“ldp”和“adsiedit”工具以连接到 test.corp。这些系统没有报告任何错误。
我们发现这很奇怪，然后我们 运行 openssl 命令查看它从同一系统提供的证书，我们发现它仍在提供不正确的证书。
经过进一步研究，似乎选择 SSL 复选框时的“ldp”和“adsiedit”工具不符合 RFC6125，特别是 B.3
，这基本上表明证书的身份必须与请求的身份匹配，否则握手将失败。此身份验证是通过使用证书公用名 (CN) 或 SAN 完成的。
据此看来工具“ldp”和“adsiedit”不符合 RFC6125 标准。
综上所述，我们需要首先修复少数提供正确证书的域控制器。我们乐于接受建议，因为过去几个月我们一直在研究这个问题。其次，有没有办法让相关的 MS 工具符合 RFC6125 标准？
如果您在连接屏幕上切换 ssl 复选框，LDP 应该会针对客户端存储验证 SSL。
也就是说，我并不惊讶它和 ADSI edit 都没有强制执行标准的那一部分，因为它们经常被用来配置或修复损坏的配置。开箱即用且没有证书服务，他们在 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 个人商店，除了从 DC 计算机商店中删除一些其他证书外，我不知道还能建议您去哪里。
RFC6125 特别指出它不会取代现有的 RFC。 LDAP 证书处理在 RFC4513 中定义。除此之外，RFC6125 还存在重大缺陷。另见 https://bugzilla.redhat.com/show_bug.cgi?id=1740070#c26
我们有一个 Microsoft Active Directory 域，其中包含大量使用 LDAP 设置的域控制器 (DC)。这些都是使用 LDAPS 设置的，并通过模板使用证书服务在主题备用名称 (SAN) 中设置带有域名（即 test.corp）的证书，供 LDAPS 服务器使用。
由于这些是 DC，因此在每个系统的池中设置了 DNS，以循环方式响应对 test.corp 的请求。
这些 DC 中的每一个在本地 Computer\Personal 证书存储中都有多个模板和多个证书。
经过测试，使用 nodejs 模块，ldapjs 在使用域名发出 LDAPS 请求时，test.corp 我们注意到少数服务器失败并显示以下消息：
Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Host: test.corp. is not in the cert's altnames: othername:, DNS:.test.corp
在调查过程中，我们发现这些少数 LDAPS 服务器提供的证书不正确。我们使用以下命令确定了这一点
openssl s_client -connect .test.corp:636
如果您将输出的证书部分放入文件中，然后使用证书管理器或 certutil 等工具读取该文件，您会发现证书不正确。 （它没有域“test.corp”SAN）。我们还通过比较序列号
验证了这一点根据我们的调查，由于我们的 DC 在本地 Computer\Personal 证书存储中有多个证书，我们发现了以下文章：
它建议将证书从本地 computer\Personal 证书存储区放入 Active Directory 域 Service\Personal 存储区。我们按照概述的步骤进行操作，但发现了相同的结果。
经过进一步调查，建议使用名为 ldp 或 adsiedit 的工具。然后，我们继续使用这些工具并欺骗我们从中进行测试的本地机器的主机文件，将域 (test.corp) 指向给我们带来麻烦的 DC 之一的 ip。重新启动以清除任何缓存后，我们测试了“ldp”和“adsiedit”工具以连接到 test.corp。这些系统没有报告任何错误。
我们发现这很奇怪，然后我们 运行 openssl 命令查看它从同一系统提供的证书，我们发现它仍在提供不正确的证书。
经过进一步研究，似乎选择 SSL 复选框时的“ldp”和“adsiedit”工具不符合 RFC6125，特别是 B.3
，这基本上表明证书的身份必须与请求的身份匹配，否则握手将失败。此身份验证是通过使用证书公用名 (CN) 或 SAN 完成的。
据此看来工具“ldp”和“adsiedit”不符合 RFC6125 标准。
综上所述，我们需要首先修复少数提供正确证书的域控制器。我们乐于接受建议，因为过去几个月我们一直在研究这个问题。其次，有没有办法让相关的 MS 工具符合 RFC6125 标准？
如果您在连接屏幕上切换 ssl 复选框，LDP 应该会针对客户端存储验证 SSL。
也就是说，我并不惊讶它和 ADSI edit 都没有强制执行标准的那一部分，因为它们经常被用来配置或修复损坏的配置。开箱即用且没有证书服务，他们在 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 个人商店，除了从 DC 计算机商店中删除一些其他证书外，我不知道还能建议您去哪里。
RFC6125 特别指出它不会取代现有的 RFC。 LDAP 证书处理在 RFC4513 中定义。除此之外，RFC6125 还存在重大缺陷。另见 https://bugzilla.redhat.com/show_bug.cgi?id=1740070#c26