My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master.
I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden <[email protected]> wrote: > Rich Megginson wrote: > >> On 04/02/2014 09:20 AM, Nevada Sanchez wrote: >> >>> Okay, we might be on to something: >>> >>> ipa -> ipa2 >>> ================================ >>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>> -h ipa2.example.com <http://ipa2.example.com> -s base -b "" >>> >>> 'objectclass=*' vendorVersion >>> dn: >>> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 >>> ================================ >>> >>> ipa2 -> ipa >>> ================================ >>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ >>> -h ipa.example.com <http://ipa.example.com> -s base -b "" >>> >>> 'objectclass=*' vendorVersion >>> ldap_start_tls: Connect error (-11) >>> additional info: TLS error -8172:Peer's certificate issuer has been >>> marked as not trusted by the user. >>> ================================ >>> >>> The original IPA trusts the replica (since it signed the cert, I >>> assume), but the replica doesn't trust the main IPA server. I guess >>> the ZZ option would have shown me the failure that I missed in my >>> initial ldapsearch tests. >>> >> -Z[Z] Issue StartTLS (Transport Layer Security) extended >> operation. If >> you use -ZZ, the command will require the operation to >> be suc- >> cessful. >> >> i.e. use SSL, and force a successful handshake >> >> >>> Anyway, what's the best way to remedy this in a way that makes IPA >>> happy? (I've found that LDAP can have different requirements on which >>> certs go where). >>> >> >> I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install >> is supposed to take care of installing the CA cert properly for you. If >> you try to hack it and install the CA cert manually, you will probably >> miss something else that ipa install did not do. >> >> I think the only way to ensure that you have a properly configured ipa >> server + replicas is to get all of the ipa commands completing >> successfully. >> >> Which means going back to the drawing board and starting over from >> scratch. >> > > You can compare the certs that each side is using with: > > # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM > > Did you by chance replace the SSL server certs that IPA uses on your > working master? > > rob >
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
