Package: 389-ds-base Version: 2.3.1+dfsg1-1 Severity: important Tags: upstream
Dear Maintainer, setting up a replication agreement between two LDAP servers via TLS port 636 based on server certificates and password-based SIMPLE authentication works without problems. The replication setup was configured using the cockpit-389-ds web interface. When switching to SSSLCLIENTAUTH the TLS connection fails with the following entries in /var/log/dirsrv/slapd-localhost/errors: - ERR - setup_ol_tls_conn - failed: unable to create new TLS context - -1 - ERR - slapi_ldap_bind - Error: could not configure the server for cert auth - error -1 - make sure the server is correctly configured for SSL/TLS - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=ldap2-to-ldap1-agreement" (ldap1:636) - Replication bind with EXTERNAL auth failed: LDAP error 0 (Success) () The source code of the setup_ol_tls_conn(LDAP *ld, int clientauth) function in https://github.com/389ds/389-ds-base/blob/389-ds-base-2.3.1/ldap/servers/slapd/ldaputil.c#L503 shows a failure to create the TLS client context in line 589: /* have to do this last - this creates the new TLS handle and sets/copies all of the parameters set above into that TLS handle context - note that optval is zero, meaning create a context for a client */ optval = 0; if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &optval))) { slapi_log_err(SLAPI_LOG_ERR, "setup_ol_tls_conn", "failed: unable to create new TLS context - %d\n", rc); } Since on Debian platform libldap uses libgnutls for the certificate-based client authentication instead of NSS, the extraction of the cacerts, the private key and the server certificate from the NSS store are required which seems to be successful: ls -l /tmp/systemd-private-e57d3846c23c4579b3beaa4d7a0f9e1b-dirsrv\@localhost.service-QfnrpZ/tmp/slapd-localhost/ -rw-r----- 1 dirsrv dirsrv 4837 Jun 18 14:06 Self-Signed-CA.pem -rw-r----- 1 dirsrv dirsrv 318 Jun 18 14:06 Server-Cert-Key.pem -rw-r----- 1 dirsrv dirsrv 2061 Jun 18 14:06 Server-Cert.pem I did quite a profound search of the Internet but I didn't find any recent problems with ssslclientauth based authentication (probably because very few people are using it). -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages 389-ds-base depends on: ii 389-ds-base-libs 2.3.1+dfsg1-1 ii acl 2.3.1-3 ii adduser 3.134 ii debconf [debconf-2.0] 1.5.82 ii ldap-utils 2.5.13+dfsg-5 ii libc6 2.36-9+deb12u7 ii libcrypt1 1:4.4.33-2 ii libdb5.3 5.3.28+dfsg2-1 ii libgcc-s1 12.2.0-14 ii libicu72 72.1-3 ii libldap-2.5-0 2.5.13+dfsg-5 ii liblmdb0 0.9.24-1 ii libmozilla-ldap-perl 1.5.3-3+b5 ii libnetaddr-ip-perl 4.079+dfsg-2+b1 ii libnspr4 2:4.35-1 ii libnss3 2:3.87.1-1 ii libpam0g 1.5.2-6+deb12u1 ii libsasl2-2 2.1.28+dfsg-10 ii libsasl2-modules-gssapi-mit 2.1.28+dfsg-10 ii libsnmp40 5.9.3+dfsg-2 ii libsocket-getaddrinfo-perl 0.22-5 ii libssl3 3.0.11-1~deb12u2 ii libsystemd0 252.22-1~deb12u1 ii perl 5.36.0-7+deb12u1 ii python3 3.11.2-1+b1 ii python3-lib389 2.3.1+dfsg1-1 ii python3-selinux 3.4-1+b6 ii python3-semanage 3.4-1+b5 ii python3-sepolicy 3.4-1 ii systemd 252.22-1~deb12u1 389-ds-base recommends no packages. 389-ds-base suggests no packages. -- Configuration Files: /etc/dirsrv/config/certmap.conf certmap default default default:DNComps dc default:FilterComps cn certmap example CN=DBMAS Issuing CA 2024-01,OU=DBMAS,O=DB InfraGO AG,C=DE example:DNComps example:FilterComps cn -- no debconf information
