<div dir="ltr">Okay. Updated the gist with the additional logs: <a href="https://gist.github.com/nevsan/8b6f78d7396963dc5f70">https://gist.github.com/nevsan/8b6f78d7396963dc5f70</a></div><div class="gmail_extra"><br><br><div class="gmail_quote"> On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson <span dir="ltr"><<a href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"><div class=""> <div>On 04/02/2014 03:01 PM, Nevada Sanchez wrote:<br> </div> <blockquote type="cite"> <div dir="ltr">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: <a href="http://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt" target="_blank">https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt</a> <div> <br> </div> <div>Let me know if I should copy it into the thread instead.</div> </div> </blockquote> <br></div> 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?<div><div class="h5"><br> <br> <blockquote type="cite"> <div class="gmail_extra"><br> <br> <div class="gmail_quote">On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson <span dir="ltr"><<a href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <div> <div>On 04/02/2014 11:45 AM, Nevada Sanchez wrote:<br> </div> <blockquote type="cite"> <div dir="ltr">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.<br> <div><br> </div> <div>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.</div> </div> </blockquote> <br> </div> I guess the next step would be to do the ipa-replica-install using -ddd and review the extra debug information that comes out. <div> <div><br> <br> <blockquote type="cite"> <div dir="ltr"> </div> <div class="gmail_extra"><br> <br> <div class="gmail_quote">On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden <span dir="ltr"><<a href="mailto:rcritten@redhat.com" target="_blank">rcritten@redhat.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Rich Megginson wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> On 04/02/2014 09:20 AM, Nevada Sanchez wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> Okay, we might be on to something:<br> <br> ipa -> ipa2<br> ================================<br> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ<br> </div> -h <a href="http://ipa2.example.com" target="_blank">ipa2.example.com</a> <<a href="http://ipa2.example.com" target="_blank">http://ipa2.example.com</a>> -s base -b "" <div><br> 'objectclass=*' vendorVersion<br> dn:<br> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751<br> ================================<br> <br> ipa2 -> ipa<br> ================================<br> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ<br> </div> -h <a href="http://ipa.example.com" target="_blank">ipa.example.com</a> <<a href="http://ipa.example.com" target="_blank">http://ipa.example.com</a>> -s base -b "" <div> <div><br> 'objectclass=*' vendorVersion<br> ldap_start_tls: Connect error (-11)<br> additional info: TLS error -8172:Peer's certificate issuer has been<br> marked as not trusted by the user.<br> ================================<br> <br> The original IPA trusts the replica (since it signed the cert, I<br> assume), but the replica doesn't trust the main IPA server. I guess<br> the ZZ option would have shown me the failure that I missed in my<br> initial ldapsearch tests.<br> </div> </div> </blockquote> <div> <div> -Z[Z] Issue StartTLS (Transport Layer Security) extended<br> operation. If<br> you use -ZZ, the command will require the operation to<br> be suc-<br> cessful.<br> <br> i.e. use SSL, and force a successful handshake<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Anyway, what's the best way to remedy this in a way that makes IPA<br> happy? (I've found that LDAP can have different requirements on which<br> certs go where).<br> </blockquote> <br> I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install<br> is supposed to take care of installing the CA cert properly for you. If<br> you try to hack it and install the CA cert manually, you will probably<br> miss something else that ipa install did not do.<br> <br> I think the only way to ensure that you have a properly configured ipa<br> server + replicas is to get all of the ipa commands completing successfully.<br> <br> Which means going back to the drawing board and starting over from scratch.<br> </div> </div> </blockquote> <br> You can compare the certs that each side is using with:<br> <br> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM<br> <br> Did you by chance replace the SSL server certs that IPA uses on your working master?<span><font color="#888888"><br> <br> rob<br> </font></span></blockquote> </div> <br> </div> </blockquote> <br> </div> </div> </div> </blockquote> </div> <br> </div> </blockquote> <br> </div></div></div> </blockquote></div><br></div>