我正在尝试在客户端(我将其称为Example, Inc.)上设置LDAP身份验证。我已经使用openssl s_client来获取证书链，但我仍然有问题。当我验证链时，我得到这个(希望忽略不相关的位):
Certificate chain
0 s:
i:/C=US/DC=com/DC=example/DC=rl/DC=example/O=Example Inc./OU=EXAMPLE/CN=XMPL L3 Low Iss E4 CA
[...]
1 s:/C=US/DC=com/DC=example/DC=rl/DC=example/O=Example Inc./OU=EXAMPLE/CN=XMPL L3 Low Iss E4 CA
i:/C=US/O=Example Inc./OU=EXAMPLE/CN=XMPL L3 INT Low CA
[...]
2 s:/C=US/O=Example Inc./OU=EXAMPLE/CN=XMPL L3 INT Low CA
i:/C=US/O=Example Inc./OU=EXAMPLE/CN=Example L3 Root CA
[...]
在我看到有人发布证书链的每个网页上，第一个(深度0)都有一个主题(s:行)。这并不是。这可能是我的问题的根源吗?
与@ChadSikorra下面的答案一致，我使用openssl x509来检查所有三个证书并寻找"关键"一词。我在以下地方找到了它。
第一个证书，带有空白主题，(XMPL L3 Low Iss E4 CA)说，
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
第二个是非空白主题，(XMPL L3 INT Low CA)说，
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name: critical
DNS:host.example.rl.example.com, DNS:host, DNS:EXAMPLE, DNS:example.rl.example.com, DNS:ldap, DNS:ldap.example.com
第三个证书(例如L3根CA)说，
X509v3 Basic Constraints: critical
CA:TRUE
这是对您所看到的问题的一个很好的解释第三方应用使用LDAP over SSL失败:
下面的问题是我经常看到的一个问题并且对于试图使用的IT管理员来说可能是一个挑战在版本2中内置了域控制器身份验证模板环境。当人们使用版本1时，可能会看到这种担忧证书，但较新的(版本2)似乎提供一些意想不到的结果。
那么问题是什么?如果你有第三方应用的话它可以通过SSL使用LDAP连接到域控制器最初使用新版本2域控制器时无法工作认证证书。
那么让我们详细讨论一下这个问题。第三方应用程序是通过SSL连接建立到域控制器的LDAP它故意做什么。这是工作时的领域控制器有一个基于"老式"版本1域的证书控制器模板。已颁发企业证书证书。但是，"域控制器"证书有已被基于"域控制器"的证书所取代"身份验证"证书的发生有几个原因在今天的这篇博文中，我们不会详细介绍。结束看到的结果是第三方应用程序现在失败了。
明显的问题是什么?默认情况下，为"域控制器"身份验证"证书有一个空白主题字段和"主题"备用名称(SAN)字段在"域"上标记为关键"控制器认证"证书。简单地说，是一些应用程序如果SAN字段被标记为关键，则无法使用证书。
为什么这个字段很重要?有些申请可能会有困难如果SAN字段被标记为"关键"，则使用证书主题字段为空白，这是由于在时检查这些字段的方式所致决定是否使用证书。
假设这是活动目录。但它可能在其他地方也有效。长话短说，LDAP SSL证书的默认DC认证模板完全省略了主题名称，以便填充主题备选名称并将其标记为关键。
然而，我知道一个事实，当使用OpenLDAP/OpenSSL库尝试通过TLS/SSL连接时，这可能导致问题。如果您正在使用OpenLDAP，您可以使用ldap_set_option和LDAP_OPT_DEBUG_LEVEL常量，并将值设置为7。然后它应该准确地告诉您它在证书方面遇到了什么问题。
您可以让他们重新颁发实际填写主题名称的新证书，或者(如果使用OpenLDAP用于库块)您可以将TLS_REQCERT选项更改为allow或none(不幸的是这会引起一些安全问题…)。