389-ds-base linked to NSS and GnuTLS, replication fails

Bug #1564179 reported by Graham Leggett
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
389-ds-base (Ubuntu)
Fix Released
Undecided
Unassigned
openldap (Debian)
Fix Released
Unknown
openldap (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

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.

Tags: gnutls nss
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

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..

Changed in 389-ds-base (Ubuntu):
status: New → Confirmed
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

would you mind testing the packages from this ppa:

https://launchpad.net/~tjaalton/+archive/ubuntu/test

it has 389-ds-base built against libldap-nss, which is built alongside the default libldap

Changed in 389-ds-base (Ubuntu):
status: Confirmed → Incomplete
Timo Aaltonen (tjaalton)
affects: 389-ds-base (Debian) → openldap (Debian)
Changed in openldap (Debian):
status: Unknown → Won't Fix
Revision history for this message
Graham Leggett (minfrin-y) wrote :

We are currently on a deadline and were forced to switch to CentOS7 to move our project forward, which worked fine out the box.

Once our deadline is over I will run tests on the above packages to see what difference they make.

Changed in openldap (Debian):
status: Won't Fix → New
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

scratch that, there's actually an effort upstream to support openssl & gnutls:

http://www.port389.org/docs/389ds/design/allow-usage-of-openldap-lib-w-openssl.html

I'll test the patch and push it in the ppa later

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package 389-ds-base - 1.3.4.9-1

---------------
389-ds-base (1.3.4.9-1) unstable; urgency=medium

  * New upstream release.
  * support-non-nss-libldap.diff: Support libldap built against gnutls.
    (LP: #1564179)

 -- Timo Aaltonen <email address hidden> Mon, 18 Apr 2016 18:08:14 +0300

Changed in 389-ds-base (Ubuntu):
status: Incomplete → Fix Released
Changed in openldap (Debian):
status: New → Won't Fix
Joshua Powers (powersj)
Changed in openldap (Ubuntu):
status: New → Won't Fix
Changed in openldap (Debian):
status: Won't Fix → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.