[389-users] Re: Replication + SSLCLIENTAUTH failure: setup_ol_tls_conn - failed: unable to create new TLS context

On 03/30/2016 06:45 PM, Graham Leggett wrote:
> On 31 Mar 2016, at 12:25 AM, Graham Leggett <minfrin@sharp.fm> wrote:
>
>>> [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) ()
>> The code looks broken, raised a bug with theoretical patch here:
>>
>> https://fedorahosted.org/389/ticket/48782
> Much stepping through code later.
>
> It turns out that on Ubuntu Trusty, 389ds the server is backed with NSS as the security library, however 389ds's replication plugin is backed with gnutls.
>
> The NSS nicknames for certfile, keyfile and cacertdir are passed into gnutls, which then fails here as follows:
>
> /* OpenSSL builds the cert chain for us, but GnuTLS
> * expects it to be present in the certfile. If it's
> * not, we have to build it ourselves. So we have to
> * do some special checks here...
> */
> rc = tlsg_getfile( lt->lt_keyfile, &buf );
> if ( rc ) return -1;
>
>
> 397 in tls_g.c
> (gdb) print rc
> $5 = <optimized out>
> (gdb) print *lt
> $6 = {
> lt_certfile = 0x7f1f9801f3a0 "Internal (Software) Token:ldap.example.com", lt_keyfile = 0x7f1f980187b0 "Server-Key", lt_dhfile = 0x0, lt_cacertfile = 0x0,
> lt_cacertdir = 0x7f1f98013960 "/etc/dirsrv/slapd-hg", lt_ciphersuite = 0x0, lt_crlfile = 0x0, lt_randfile = 0x0,
> lt_protocol_min = 768}
> (gdb) print buf
> $7 = 0x0
>
> The "return -1" above is the origin of the "-1" return code in the logged error message.
>
> Running ldd against the ns-slapd binary shows this (snipped):
>
> root@ldap.example.com:~/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)
>
> It looks like no kind of replication could ever work on Ubuntu Trusty, as NSS parameters are passed to gnutls, which can only fail.
>
> Has anyone seen this kind of thing before?

https://fedorahosted.org/389/ticket/47536

It's not that "389ds's replication plugin is backed with gnutls", it is
that 389ds replication uses openldap, which uses gnutls on ubuntu, and
389ds, for the moment, assumes that openldap is backed by NSS.

>
> Regards,
> Graham
> —
> --
> 389 users mailing list
> 389-users@%(host_name)s
> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org