☰

使用 Let's Encrypt 证书的 LDAP 复制到服务器失败，“无法获取颁发者证书”

tag-icon • tag-icon ssl ldap lets-encrypt 389-ds
使用 Let's Encrypt 证书的 LDAP 复制到服务器失败，“无法获取颁发者证书”

我目前正在尝试在 389 目录服务器实例（均在 Fedora 37 上运行）之间设置 LDAP 复制，在下面我将其称为 $SUPPLIER 和 $CONSUMER（分别在域 supplier.mydomain.example 和 consumer.mydomain.example 上提供服务）。

$SUPPLIER 和 $CONSUMER 的配置相同，并且使用 Let's Encrypt 证书。我已成功配置了 $SUPPLIER 的几个客户端，它们都运行良好（都使用 ldaps:// 与 $SUPPLIER 进行通信，并要求其提供 TLS 证书）。

但是，从 $SUPPLIER 复制到 $CONSUMER 不起作用。我收到以下错误消息：

[02/May/2023:14:28:07.389193770 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=Synchronize with $CONSUMER" (ldap3:636) - Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) (error:0A000086:SSL routines::certificate verify failed (unable to get issuer certificate))
[02/May/2023:14:28:10.408516918 +0200] - ERR - slapi_ldap_bind - Could not send bind request for id [cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 (Invalid function argument.), network error 0 (Unknown error, host "consumer.mydomain.example:636")

如何解决“无法获取颁发者证书”错误？

我已经找到的有关该问题的大部分内容都假设使用自签名证书并且需要手动安装 CA；然而，我认为让像 Let's Encrypt 这样的 CA 颁发证书的全部笑话在于该 CA 已经受到所有操作系统/应用程序的信任（例如，就像浏览器的情况一样，我可以自动连接到受 Let's Encrypt 保护的网站）。

有用的东西

[email protected]$ dsconf -D "cn=replication manager,cn=config" ldaps://consumer.mydomain.example:636 monitor server
dn: cn=monitor
version: 389-Directory/2.3.3
...

任何其他有效的dsconf（或可能也是dsidm）命令也有效，即这里的加密连接没有错误。

[email protected]$ echo -n "" | openssl s_client -showcerts consumer.mydomain.example:636
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = consumer.mydomain.example
verify return:1
---
Certificate chain
 0 s:CN = consumer.mydomain.example
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Apr 10 18:33:38 2023 GMT; NotAfter: Jul  9 18:33:37 2023 GMT
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
---
Server certificate
subject=CN = consumer.mydomain.example
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4205 bytes and written 424 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE

[email protected]$ trust list
[...]
pkcs11:id=%79%B4%59%E6%7B%B6%E5%E4%01%73%80%08%88%C8%1A%58%F6%E9%9B%6E;type=cert
    type: certificate
    label: ISRG Root X1
    trust: anchor
    category: authority
[...]

不起作用的东西

[email protected]$ echo -n | openssl s_client -connect consumer.mydomain.example:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/ldapserver.pem
[email protected]$ openssl verify /tmp/ldapserver.pem  
CN = consumer.mydomain.example
error 20 at 0 depth lookup: unable to get local issuer certificate
error ldapserver.pem: verification failed

这似乎与 LDAP 服务器日志中的错误消息相同，所以这两个问题也许有关联？

更新：每dave_thompson_085 的评论，这似乎更像是一个转移注意力的话题，因为这个命令显然总是会失败，所以在这里失败也就不足为奇了。

有关的

  1. 无法与 STARTTLS 建立复制 - 389-用户 - Fedora 邮件列表：问题看起来非常相似（而且相当新），尚未解决。
  2. 旧版 Let's Encrypt 根证书到期和 OpenSSL 1.0.2：如果这是两年前的问题，那么这可能是一个问题，但是，我预计它不会在 2023 年对现代操作系统造成任何问题。
  3. 无法openssl verify加密证书-untrusted建议在使用时使用选项openssl verify，但是，我无法将此选项传递给 389 DS，并且我也不想将-untrusted标志放在生产环境附近的任何地方。
  4. 0A000086似乎是 OpenSSL 发出的错误代码（参见例如此网络搜索)，所以问题可能出在 OpenSSL 上，而不是 389 Directory Server 上？
  5. 一个可能相关的错误，讨论 389 DS 如何链接到两个加密库，这可能会导致问题
  6. 的源代码slapi_ldap_bind，引发错误消息

答案1

错误消息表明：无法获取颁发者证书，这表明 LDAP 服务存在 PKI 信任问题，也可能是系统存在 PKI 信任问题。
我将添加并信任颁发 LDAP SSL 服务器证书的信任链中的所有颁发者。进入 LDAP NSS db 目录，

certutil -A -d xx -n xx -t CT -a -i some.ca.cert.pem.txt

以及在带有trust anchor some.ca.cert.pem.txtp11-kit 的系统上，假设这是 RHEL-9 或 RHEL-8，或者 Fedora。

这需要在每个副本上完成，并且 LDAP 客户端上也需要信任锚。

然后在本地、跨副本以及从一些 LDAP 客户端使用 LDAPS 和 STARTTLS 运行一些测试 ldapsearch 命令。

-d 4如果出现问题，请在测试命令中添加“ ldapsearch，但我希望提供相同的发行者信任消息。
请注意，提供的默认 LDAP SSL 服务器证书只是一个测试“虚拟”证书，用于显示开箱即用的功能，需要更换。还请注意，在测试和比较时，每个客户端工具都有不同的要求。

例如，使用 OpenSSL s_client 将具有与 OpenLDAP 客户端的 ldapsearch、Java 客户端或 Python 客户端或 SSSD 等不同的行为。

相关内容