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 <> -s base -b ""
'objectclass=*' vendorVersion
vendorVersion: 389-Directory/ B2014.073.1751

ipa2 -> ipa
$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ
-h <> -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-

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?


Freeipa-users mailing list

Reply via email to