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 <rcrit...@redhat.com <mailto:rcrit...@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



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to