<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><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 class="">
<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 class="h5"><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>