<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><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 class="">
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 class="">
Okay, we might be on to something:<br>
<br>
ipa -> ipa2<br>
==============================<u></u>==<br>
$ LDAPTLS_CACERTDIR=/etc/dirsrv/<u></u>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 class=""><br>
'objectclass=*' vendorVersion<br>
dn:<br>
vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751<br>
==============================<u></u>==<br>
<br>
ipa2 -> ipa<br>
==============================<u></u>==<br>
$ LDAPTLS_CACERTDIR=/etc/dirsrv/<u></u>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 class="h5"><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>
==============================<u></u>==<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 class="h5">
        -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-<u></u>replica-prepare/ipa-replica-<u></u>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 class="HOEnZb"><font color="#888888"><br>
<br>
rob<br>
</font></span></blockquote></div><br></div>