我有一个在 Windows Server 2019 上运行的 DC，并且它安装了域服务角色。我使用 AD CS 角色在同一域中设置了一个多层 CA（根 CA 已关闭、中间 CA 已关闭、发行 CA 已打开并已加入域）。
我无法让第三方客户端（即未加入域的计算机和/或 Web 应用程序）通过 LDAPS/636 进行 BIND。它们在 LDAP/389 上工作得很好，有些还可以与 StartTLS 配合使用，尽管这并不总是一种选择，我更喜欢使用正确的 LDAPS。
我已为 AD 服务器生成证书，并确保在证书主题中使用其 FQDN，并将其 DNS 主机名和 IP 地址作为 SAN 包含在内，以涵盖所有基础。我还确保已在增强密钥使用扩展中选择了“服务器身份验证”。
由于我无法远程访问该环境，因此我尚未验证这一点，但我们假设证书是按照 Microsoft 的文档使用 Schannel CSP 生成的。该证书由正确的颁发 CA 签名，并且客户端安装了整个 CA 链，并且可以在本地验证 AD 证书（如果我从 AD 导出证书并将其复制到其中一个客户端）
奇怪的地方就在这里：如果我跳转到 AD 服务器，打开ldp.exe，我可以使用 SSL 通过 LDAPS/636 进行连接，并Host supports SSL, SSL cipher strength = 256 bits出现在输出/控制台视图中。但是，如果我跳转到其中一个客户端（例如 Linux 计算机）并尝试使用 openssl 进行连接：
openssl s_client -showcerts -state -connect <AD_FQDN>:636
我没有获得证书；而是获得了这个（由于网络的性质，我必须将其写下来而不是复制/粘贴，因此可能会有轻微的不准确之处）：
CONNECTED (00000003)
write: errno = 104
---
no peer certificate available
---
No client cert CA names sent
---
SSL handshake has read 0 bytes and written 324 bytes
Verification: OK
---
<snip>
确实，如果我尝试设置客户端以使用 LDAPS 进行身份验证，我仍无法使其正常工作。通常我会看到类似以下无用错误的内容：SSL_Certificate error: Connection closed by peer根据我的经验，这通常表示证书验证/信任问题（如果客户端甚至没有获得证书进行验证，则这种情况是合理的）。其他一些客户端甚至更没有帮助，只是说“无法绑定到 LDAP 服务器”
DC 肯定在监听端口 636，我可以从客户端外部连接到它（即不仅仅是在 DC 机器内的环回上），我已经使用 netcat 进行了验证
nc -vz <AD_FQDN> 636
有什么想法可能导致此问题的原因吗？
答案1
原来我们的防火墙正在执行应用程序检查并中断 SSL 连接。关闭应用程序检查解决了我的问题。