Hi,
John Oliver a écrit :
[root@localhost ~]# ldapsearch -H ldaps://ldap2.mydomain.com -b "dc=mydomain,dc=com" uid=joliver sn givenName cn ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
This is a SSL error message: your LDAP client can not identify the certificate authority that emitted the certificate presented by your server. Configure your ldap.conf file to include appropriate files (TLS_CACERT or TLS_CACERTDIR, etc).
[root@localhost ~]# ldapsearch -H ldap://ldap2.mydomain.com -b "dc=mydomain,dc=com" uid=joliver sn givenName cn SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
When using just ldap:// with ldapsearch, I don't know what password it's asking for. My LDAP password doesn't work, the LDAP admin password doesn't work, the local root password doesn't work...
This is because ldapsearch is trying to authenticate using SASL authentication layer. Add the "-x" option to your ldapsearch command, and you can use your LDAP password.
Here's the odd thing. When I started setting this up, the machine that's the primary (and working) LDAP server now was running fedora-ds. I set up OpenLDAP on what is now the slave server, and it worked perfectly. I slapcat'ed it, installed OpenLDAP on the primary server, and slapadded the db. I never generated any certificates on it at all, and it works perfectly. I just regenerated the cert on the slave server, but no joy.
I believe OpenSSL defaults have become more strict in certificate checking, over some recent (maybe up to 6 months ago) upgrade.
Jonathan