Okay. Updated the gist with the additional logs: https://gist.github.com/nevsan/8b6f78d7396963dc5f70
On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson <[email protected]> wrote: > On 04/02/2014 03:01 PM, Nevada Sanchez wrote: > > 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. > > > Ok. Now can you post excerpts from the dirsrv errors log from both the > master replica and the replica from around the time of the failure? > > > > > On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson <[email protected]>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 <[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
