> On 26 Sep 2019, at 00:58, Mark Reynolds <mreynolds@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxxxxxxxxxx > > -- > > 389 Directory Server Development Team > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
