Okay, I ran it with debug on. The output is quite large. I'm not sure what the etiquette is for posting large logs, so I threw it on gist here: https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt<http://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt>
Let me know if I should copy it into the thread instead. On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson <rmegg...@redhat.com> wrote: > On 04/02/2014 11:45 AM, Nevada Sanchez wrote: > > 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. > > > I guess the next step would be to do the ipa-replica-install using -ddd > and review the extra debug information that comes out. > > > > > On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden <rcrit...@redhat.com>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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users