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

[Nevada Sanchez]

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.


On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden <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> -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140402/f14424a8/attachment.htm>