On 26 Sep 2019, at 00:58, Mark Reynolds <mreynolds(a)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...
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/repl...
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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
--
389 Directory Server Development Team
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs