> On 26 Sep 2019, at 00:58, Mark Reynolds <mreyno...@redhat.com> wrote: > > > On 9/25/19 10:43 AM, Eugen Lamers wrote: >> I'm trying to setup a replication with a certificate based authentication >> between supplier and consumer. The certificates in the certdb at >> /etc/dirsrv/slapd-XXX contain the very same CA with which the respective >> server certificates in the certdbs have been signed. The certificates all >> have the 'u' flag, and the CA has the C and T flag. >> The replication (on the supplier) has been setup such that TLS and >> certificate based authentication is used, see extract from the replication >> agreement object: >> >> objectclass: nsds5ReplicationAgreement >> nsds5replicahost: <consumer-hostname> >> nsds5replicaport: 389 >> nsds5replicatransportinfo: TLS >> nsds5replicabindmethod: SSLCLIENTAUTH >> >> Trying to initialize the consumer raises this error in the error-log of the >> supplier (the host sending the starttls connection request): >> Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate >> authentication) (missing client certificate) > > Replication does not use the server's certificate for SSL Client > Authentication. It uses the client certificate in the "Replication Manager" > entry. Sounds like you did not add a user certificate to this entry. > > Look at this for help with adding a client certificate to a user entry: > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/using-based_client_authentication > > Note - the client certificate you use in the replication manager but be > issued by the same CA that the all the replicas are using.
I think there is also a test case somewhere in the server that uses TLS auth for the replication manager https://pagure.io/389-ds-base/blob/master/f/dirsrvtests/tests/suites/replication/tls_client_auth_repl_test.py It might help give you some ideas on how this works, > > HTH, > > Mark > > >> >> The certificate that the server should have sent can, however, be used with >> the ldap commandline tools as ldapsearch. In this case a wireshark trace >> clearly shows that the client sends the certificate during the TLS >> handshake, while in the above case it doesn't. >> The TLS handshake defines that the client has to send an "empty certificate" >> if it does not have a certificate that has been issued by a CA offered by >> the server during the handshake. I can't see a reason for the client to >> think the condition isn't met. The certificate with which the server >> (supplier) is setup is the only one available. >> Is it possible that the server does not know which certificate it has to use >> for authentication with the consumer server? And if so, how do I make the >> server know? >> >> The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the >> same with 1.4.0.3. >> >> Thanks, >> Eugen >> _______________________________________________ >> 389-users mailing list -- 389-users@lists.fedoraproject.org >> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > -- > > 389 Directory Server Development Team > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
