# LDAPTLS_CACERTDIR=/etc/ssl/certs/ ldapwhoami -x -ZZ -H ldaps://ldap.domain.tld ldap_start_tls: Can't contact LDAP server (-1) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. # openssl s_client -connect ldap.domain.tld:636 -CApath /etc/ssl/certs <... successful tls negotiation stuff ...> Compression: 1 (zlib compression) Start Time: 1349994779 Timeout : 300 (sec) Verify return code: 0 (ok) ---
openssl似乎认为证书很好,但openldap的库(pam_ldap表现出类似的行为,这就是我如何处理这个混乱)不同意.
我究竟做错了什么?
Debian和衍生产品以这种格式提供/ etc / ssl / certs; / etc / ssl / certs是Debian上的规范信任存储位置,而IMO提供它的任何东西都应该像Debian一样,因为Debian的目录与1999年一样大致相同.RHEL有一个/ etc / ssl / certs目录,但它不是这种格式 – 它根本不包含任何单独的证书文件.您不能将其用作CApath.老实说,在RHEL(以及Fedora和衍生产品)上,该目录基本上是一个陷阱.不要使用它. (有关它为什么存在的一些背景,以及我如何解决这个问题,请参见https://bugzilla.redhat.com/show_bug.cgi?id=572725和https://bugzilla.redhat.com/show_bug.cgi?id=1053882).所以我认为你正在发生的事情是正确的,但错误的原因是什么. OpenLDAP没有做错任何事情,并且它没有失败,因为“ca-bundle.trust.crt …是一个Mozilla NSS证书/密钥数据库”(那些被称为cert8 / 9.db和key3 / 4.db,以及RHEL上的系统级系统位于/ etc / pki / nssdb),它只是失败,因为/ etc / ssl / certs根本不能用作“证书目录”.
RHEL在其他任何地方都不提供可用作CApath样式信任库的任何东西. RHEL的系统信任存储作为单个PEM捆绑文件(OpenSSL术语中的“CAfile”)提供,可在/etc/pki/tls/certs/ca-bundle.crt和/ etc / pki / tls / cert中找到.质子交换膜.它也可以在/etc/ssl/certs/ca-bundle.crt找到,因为/ etc / ssl / certs实际上只是/ etc / pki / tls / certs的符号链接,但该位置不是规范的,真的不应该’什么都可以使用. RHEL还提供OpenSSL的“可信证书”格式的捆绑包/etc/pki/tls/certs/ca-bundle.trust.crt.
正如您所知,正确的做法是使用系统提供的捆绑文件.你的答案是有效的,但由于上述原因,我强烈建议TLS_CACERT = / etc / pki / tls / certs / ca-bundle.crt或TLS_CACERT = / etc / pki / tls / cert.pem超过TLS_CACERT = / etc /ssl/certs/ca-bundle.crt.
(顺便说一下,没有什么是新的,但是互联网的混乱很普遍.RH和衍生品从来没有提供过完整的证书目录.他们从2000年开始就提供了一个捆绑文件.它是在2005年从/usr/share / ssl迁移到/ etc / pki / tls.Debian将/ etc / ssl / certs作为CApath样式的目录和/etc/ssl/certs/ca-certificates.crt作为捆绑包自石器时代起或多或少的文件.)