[Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)

[Rich Megginson]

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 <rcritten at redhat.com 
> <mailto:rcritten at 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>
>             <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>
>             <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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140402/9533663d/attachment.htm>