The ns-slapd binary is currently linked to two separate SSL libraries, NSS for server connections, and gnutls for client connections via openldap:
<email address hidden>:~/src/openldap-2.4.31# ldd /usr/sbin/ns-slapd
libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so
(0x00007f0e14e60000)
libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26
(0x00007f0e12def000)
Because 389ds's replication plugin passes parameters that are only understandable by NSS to the gnutls library, all attempts to replicate over SSL fails as follows:
[30/Mar/2016:17:19:19 +0000] setup_ol_tls_conn - failed: unable to create
new TLS context
[30/Mar/2016:17:19:19 +0000] slapi_ldap_bind - Error: could not configure
the server for cert auth - error -1 - make sure the server is correctly
configured for SSL/TLS
[30/Mar/2016:17:19:19 +0000] NSMMReplicationPlugin - agmt="cn=Agreement
ldap.example.com" (ldap:636): Replication bind with EXTERNAL auth failed:
LDAP error 0 (Success) ()
These messages are caused by NSS certificate nicknames being interpreted by gnutls as filesystem paths, triggering failures.
To fix this, 389ds needs to be linked against an LDAP client library that is also linked to NSS.
Right now 389ds cannot be used on Trusty at all in any kind of meaningful way.
Correct, and I'm not sure that's going to change. My priorities are with FreeIPA and 4.3 uses GSSAPI for the replication and this works fine with the test packages. Still unsure if all the bits will land in 16.04 though..