Hide Forgot
$ ldapsearch -H ldaps://corpad.intel.com:3269 -b 'dc=corp,dc=intel,dc=com' sAMAccountName=dwoodhou ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: TLS error -8179:Peer's Certificate issuer is not recognized. Repeating with debugging shows: TLS: certificate [CN=Intel Intranet Basic Policy CA,O=Intel Corporation,C=US] is not valid - error -8179:Peer's Certificate issuer is not recognized.. tls_write: want=7, written=7 0000: 15 03 03 00 02 02 30 ......0 TLS: error: connect - force handshake failure: errno 2 - moznss error -8179 TLS: can't connect: TLS error -8179:Peer's Certificate issuer is not recognized.. But this is nonsense. that CA *is* installed in the system and working correctly. OpenLDAP is misbehaving. $ openssl s_client -connect corpadssl.intel.com:3269 | openssl x509 -noout -text | grep -A1 'Authority Key Ident' depth=3 C = US, O = Intel Corporation, CN = Intel Root CA verify return:1 depth=2 C = US, O = Intel Corporation, CN = Intel Intranet Basic Policy CA verify return:1 depth=1 C = US, O = Intel Corporation, CN = Intel Intranet Basic Issuing CA 2A verify return:1 depth=0 CN = fmscorp401.corp.intel.com verify return:1 X509v3 Authority Key Identifier: keyid:95:F5:A8:CD:2A:A4:B3:FF:1D:36:92:75:4A:82:93:92:7A:87:E7:DC $ p11tool --export 'pkcs11:token=System%20Trust;id=%95%F5%A8%CD%2A%A4%B3%FF%1D%36%92%75%4A%82%93%92%7A%87%E7%DC' | openssl x509 -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 61:11:dc:82:00:01:00:00:00:14 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=Intel Corporation, CN=Intel Intranet Basic Policy CA Validity Not Before: Feb 4 21:52:13 2013 GMT Not After : May 24 19:59:39 2018 GMT Subject: C=US, O=Intel Corporation, CN=Intel Intranet Basic Issuing CA 2A ...
Hello, If I understand this correctly this should be due to current default settings. OpenLDAP's trust settings are based purely on its own settings (see TLS_CACERT, TLS_CACERTDIR and their variants described in manpages ldap.conf(5), slapd.conf(5), and slapd-config(5)). Currently, by default the TLS_CACERT is empty (thus without an effect), and TLS_CACERTDIR is set to /etc/openldap/certs which is empty (thus without an effect, too). If you agree then I would close this as NOTABUG as the issue you are experiencing is probably purely due to the configuration. Once the bug 1270678 is resolved the OpenLDAP in Fedora will honour the Fedora Shared System Certificates which should make your ldapsearch command in the Description work as expected. Regards
Turns out I have an ldap.conf.rpmnew with 'TLS_CACERTDIR /etc/openldap/certs' while the active ldap.conf uses the non-existedn /etc/openldap/cacerts. So it looks like it has actually been done, but there's an issue with upgrades? From my point of view, then, this bug could be closed. But Artem tells me that his *does* point to /etc/openldap/certs and he still has the problem? Artem, can you just use 'TLS_CACERT /etc/pki/tls/cert.pem' and does that make it work? This is specifically for the 'issuer is not recognized' error, and *not* the orthogonal 'cert is expired' error that you were seeing in a different place.
Yes, I do not have /etc/openldap/certs at all, and using 'TLS_CACERT /etc/pki/tls/cert.pem' fixes the problem you reported.
(In reply to David Woodhouse from comment #2) > Turns out I have an ldap.conf.rpmnew with 'TLS_CACERTDIR > /etc/openldap/certs' while the active ldap.conf uses the non-existedn > /etc/openldap/cacerts. So it looks like it has actually been done, but > there's an issue with upgrades? > The change from /etc/openldap/cacerts to /etc/openldap/certs seems to have been introduced quite a time ago with bug 772890. There's not an issue per se. When updating config files mostly it is safer not to change user-modified files. Rather, a new config file is created along appended with .rpmnew, so that user may check this new file and make updates accordingly. > From my point of view, then, this bug could be closed. But Artem tells me > that his *does* point to /etc/openldap/certs and he still has the problem? Yes, because in /etc/openldap/certs there is no CA cert file, thus no one to trust. This is not a bug per se, rather an inconvenience which will be resolved with bug 1270678. Thanks. Thus, I am closing as NOTABUG.