Just as a follow up to this, on ~5% of our hosts (RHEL[456]), crond would be unable to connect to the ldapserver after /etc/ldap.conf was updated to use SSL. Restarting crond fixed the issue. On Thu, Jul 19, 2012 at 10:54 AM, David Nguyen <d_k_nguyen@xxxxxxxxx> wrote: > The cert is self-signed, but by different CA's (each server has it's own CA). > > You know what? I took your hint and signed a new server cert using > the "working" ldap server's CA and voila, it started working. Thank > you so much! I've been scratching my head over this one for days > > > David > > On Thu, Jul 19, 2012 at 6:34 AM, Carsten Grzemba <grzemba@xxxxxxxxxxxx> wrote: >> Hi, >> >> what kind of certificate do you use, selfsigned? Are the certificates signed >> by the same CA? >> >> >> >> Am 18.07.12, schrieb David Nguyen <d_k_nguyen@xxxxxxxxx>: >> >> Hi all, >> >> I have a strange one. My current setup is working perfectly. client1 >> is able to connect to ldap-server1 via SSL and everything is working >> correctly. I then had a need to add another ldap server (ldap-server2) >> as a multi-master replica and everything is working (user auth, sudo >> via ldap users, ldapsearch, openssl, etc) except cronjobs for users >> served out of ldap fail to run. >> >> I can see this in the error log on ldap-server2: >> >> [18/Jul/2012:11:18:00 -0700] - PR_Recv for connection 467 returns >> -12195 (Peer does not recognize and trust the CA that issued your >> certificate.) >> >> If I set /etc/ldap.conf to not use SSL (URI ldap://fqdn vs URI >> ldaps://fqdn:636), the cronjobs fire just fine. >> >> So it appears as though there is an SSL cert issue, but I'm stumped >> because all of the other services that use ldap on client1 work except >> cron jobs (root cron fires fine as expected since nsswitch is set to >> files then ldap). >> >> If I replace the URI string in /etc/ldap.conf to point at >> ldap-server1, cron starts working. >> >> Both ldap-server1 and ldap-server2 are using running the same OS and >> kernel version (RHEL5) as well as the same version of 389 DS >> (389-ds-1.2.1-1.el5). >> >> Any ideas as to what could be causing this problem? Here is the >> /etc/ldap.conf on client1 if it matters: >> >> ====== begin /etc/ldap.conf ======= >> URI ldaps://ops-ldap006.svale.netledger.com:636 >> base dc=netsuite,dc=com >> >> timelimit 10 >> bind_policy soft >> nss_reconnect_tries 3 >> bind_timelimit 6 >> idle_timelimit 30 >> sudoers_base ou=SUDOers,dc=netsuite,dc=com >> sudoers_debug 0 >> >> ##ssl start_tls >> TLS_CACERT /etc/openldap/cacerts/ca.crt >> TLS_CACERTFILE /etc/openldap/cacerts/ca.crt >> TLS_REQCERT demand >> pam_lookup_policy yes >> pam_password exop >> >> nss_initgroups_ignoreusers >> root,named,avahi,haldaemon,dbus,gdm,postfix,puppet >> >> ====== end /etc/ldap.conf ======= >> >> >> >> >> Thanks in advance, >> David >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> >> -- >> Carsten Grzemba >> >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
