openLDAP 证书不受信任或已被撤销

Question 1

我终于明白了为什么要考虑证书untrusted or revoked。

我的证书是使用 Apache HTTPD 模块mod_md带有MDMustStaple指令生成的On。

OpenLDAP 不处理OCSP Stapling。

我向 LE 请求了不带 OCSP 必须装订标志的新证书，现在一切都运行正常，ldap*无论是命令还是syncrepl流程。

Answer

我终于明白了为什么要考虑证书untrusted or revoked。

我的证书是使用 Apache HTTPD 模块mod_md带有MDMustStaple指令生成的On。

OpenLDAP 不处理OCSP Stapling。

我向 LE 请求了不带 OCSP 必须装订标志的新证书，现在一切都运行正常，ldap*无论是命令还是syncrepl流程。

Question 2

尝试安装软件包libldap-common。它不会ldap-utils在我们的环境中作为依赖项自动安装。安装软件包后，错误消失，我们能够连接到使用 LetsEncrypt 证书的 LDAP 服务器。

如果您遇到以下错误，您也必须安装libsasl2-modules：

ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
    additional info: SASL(-4): no mechanism available: No worthy mechs found

Answer

尝试安装软件包libldap-common。它不会ldap-utils在我们的环境中作为依赖项自动安装。安装软件包后，错误消失，我们能够连接到使用 LetsEncrypt 证书的 LDAP 服务器。

如果您遇到以下错误，您也必须安装libsasl2-modules：

ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
    additional info: SASL(-4): no mechanism available: No worthy mechs found

Question 3

理解的关键TLS: peer cert untrusted or revoked (0x80002)是解码数字。错误消息由 OpenLDAP 生成，但数字错误代码来自 GnuTLS。

https://codesearch.debian.net发现此错误消息仅在https://sources.debian.org/src/openldap/2.5.13+dfsg-5/libraries/libldap/tls_g.c/?hl=1195#L1195，这表明该数字由存储gnutls_certificate_verify_peers2()，其手册页说：“此函数将验证对等方的证书，并将状态存储在状态变量中，作为 gnutls_certificate_status_t 值的按位或，如果证书受信任，则存储为零。”

gnutls_certificate_status_t 的值定义在格努特尔斯. 当前列表：

typedef enum {
    GNUTLS_CERT_INVALID = 1 << 1,                           //      0x2
    GNUTLS_CERT_REVOKED = 1 << 5,                           //     0x20
    GNUTLS_CERT_SIGNER_NOT_FOUND = 1 << 6,                  //     0x40
    GNUTLS_CERT_SIGNER_NOT_CA = 1 << 7,                     //     0x80
    GNUTLS_CERT_INSECURE_ALGORITHM = 1 << 8,                //    0x100
    GNUTLS_CERT_NOT_ACTIVATED = 1 << 9,                     //    0x200
    GNUTLS_CERT_EXPIRED = 1 << 10,                          //    0x400
    GNUTLS_CERT_SIGNATURE_FAILURE = 1 << 11,                //    0x800
    GNUTLS_CERT_REVOCATION_DATA_SUPERSEDED = 1 << 12,       //   0x1000
    GNUTLS_CERT_UNEXPECTED_OWNER = 1 << 14,                 //   0x4000
    GNUTLS_CERT_REVOCATION_DATA_ISSUED_IN_FUTURE = 1 << 15, //   0x8000
    GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE = 1 << 16,       //  0x10000
    GNUTLS_CERT_MISMATCH = 1 << 17,                         //  0x20000
    GNUTLS_CERT_PURPOSE_MISMATCH = 1 << 18,                 //  0x40000
    GNUTLS_CERT_MISSING_OCSP_STATUS = 1 << 19,              //  0x80000
    GNUTLS_CERT_INVALID_OCSP_STATUS = 1 << 20,              // 0x100000
    GNUTLS_CERT_UNKNOWN_CRIT_EXTENSIONS = 1 << 21           // 0x200000
} gnutls_certificate_status_t;

例如，0x80002是 GNUTLS_CERT_MISSING_OCSP_STATUS + GNUTLS_CERT_INVALID。所以它直接指向与 OCSP 相关的问题。可惜错误消息太糟糕了。

在我的例子中，错误TLS: peer cert untrusted or revoked (0x42)等于 GNUTLS_CERT_SIGNER_NOT_FOUND + GNUTLS_CERT_INVALID。这仍然不是很有用。

GnuTLS 有一个命令行工具gnutls-cli可以显示更多详细信息。它与 OpenSSL 类似，openssl s_client但最好使用正确的工具，因为它们的行为并不总是相同的。在 Debian 上，它是通过来安装的apt install gnutls-bin。

# Connect to LDAPS:
$ gnutls-cli ldap.example.com:636

# Connect to LDAP with STARTTLS:
$ gnutls-cli --starttls-proto=ldap ldap.example.com:389

在我的特定情况下，问题在于我们的 LDAP 服务器配置错误，它在链中发送了两次叶证书。OpenSSL 对此没有异议，但 GnuTLS 拒绝了它。修复方法是在 LDAP 服务器配置中使用.../chain.pem而不是.../fullchain.pem。要找到根本原因，将坏 LDAP 服务器和具有相同证书的正常工作的 HTTPS 服务器之间的 gnutls-cli 输出进行比较非常有帮助。我不知道其他人是否也会遇到同样的问题，但至少这是 gnutls-cli 如何提供帮助的一个很好的例子。

$ gnutls-cli --starttls-proto=ldap example.com:389
Processed 137 CA certificate(s).
Resolving 'example.com:389'...
Connecting to '[...]:389'...
- Certificate type: X.509
- Got a certificate list of 4 certificates.
- Certificate[0] info:
 - subject `CN=*.example.com', issuer `CN=R3,O=Let's Encrypt,C=US', serial [...], EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2023-11-24 xx:xx:xx UTC', expires `2024-02-22 xx:xx:xx UTC', pin-sha256="[...]"
- Certificate[1] info:
 - subject `CN=*.example.com', issuer `CN=R3,O=Let's Encrypt,C=US', serial [...], EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2023-11-24 xx:xx:xx UTC', expires `2024-02-22 xx:xx:xx UTC', pin-sha256="[...]"
- Certificate[2] info:
 - subject `CN=R3,O=Let's Encrypt,C=US', issuer `CN=ISRG Root X1,O=Internet Security Research Group,C=US', serial 0x00912b084acf0c18a753f6d62e25a75f5a, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-09-04 00:00:00 UTC', expires `2025-09-15 16:00:00 UTC', pin-sha256="jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0="
- Certificate[3] info:
 - subject `CN=ISRG Root X1,O=Internet Security Research Group,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x4001772137d4e942b8ee76aa3c640ab7, RSA key 4096 bits, signed using RSA-SHA256, activated `2021-01-20 19:14:03 UTC', expires `2024-09-30 18:14:03 UTC', pin-sha256="C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M="
- Status: The certificate is NOT trusted. The certificate issuer is unknown.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.

最后，请注意 gnutls-cli 会自动加载操作系统的证书颁发机构，但 ldapsearch 只有在正确配置的情况下才会加载它们。

这就是为什么ForJ9 的回答建议安装libldap-common。它是一个 Debian 包，仅包含一个文件/etc/ldap/ldap.conf（和一些文档），该文件仅包含一行未注释的行：

TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

为了稳健性，您可以直接在 ldapsearch 命令行上设置此选项，如下所示：

ldapsearch -v -d 65535 -ZZ -H ldap://example.com:389/ -o tls_cacert=/etc/ssl/certs/ca-certificates.crt -x '(objectClass=*)'

Answer