TLS_CACERTDIR not supported in gnutls

Bug #242313 reported by Laurent Pinchart on 2008-06-23
78
This bug affects 13 people
Affects Status Importance Assigned to Milestone
gnutls26 (Ubuntu)
Undecided
Unassigned
openldap (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: libldap-2.4-2

Description: Ubuntu 8.04
Release: 8.04

libldap-2.4-2:
  Installed: 2.4.7-6ubuntu4.2
  Version table:
 *** 2.4.7-6ubuntu4.2 0
        100 /var/lib/dpkg/status
     2.4.7-6ubuntu3 0
        500 http://be.archive.ubuntu.com hardy/main Packages

Switching to gnutls for openldap in Hardy introduced a regression by breaking the TLS_CACERTDIR option in /etc/ldap/ldap.conf. Unlike openssl, gnutls doesn't certficate directories natively.Upgrading a secured openldap setup using TLS_CACERTDIR from Gutsy to Hardy breaks connections to the openldap server.

Chuck Short (zulcss) wrote :

Can you try the version from hardy-updates?

Thanks
chuck

Changed in openldap2.3:
status: New → Incomplete

libldap-2.4-2:
  Installed: 2.4.9-0ubuntu0.8.04
  Candidate: 2.4.9-0ubuntu0.8.04
  Version table:
 *** 2.4.9-0ubuntu0.8.04 0
        500 http://be.archive.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     2.4.7-6ubuntu3 0
        500 http://be.archive.ubuntu.com hardy/main Packages

Same issue.

Chuck Short (zulcss) wrote :

Please include the log file when this happens

Thanks
chuck

ldapsearch -ZZ -x -d 1 prints the following messages (stripped from unrelated information for the sake of clarity)

TLS: warning: cacertdir not implemented for gnutls
TLS: peer cert untrusted or revoked (0x42)

Gary Wilson (gary-wilson) wrote :

I can confirm the "cacertdir not implemented for gnutls" warning message. The same setup that worked for me on Gutsy no longer works on Hardy.

I had only added the following option to my /etc/ldap/ldap.conf file:

TLS_CACERTDIR /usr/share/ca-certificates/mozilla

However, while this ticket might be valid as far as support for TLS_CACERTDIR goes, it appears that the actual connection problems are a different problem (see bug #257153). There, the user is using the TLS_CACERT option, is not getting any gnutls warning, and is still getting the same connection error.

Changed in openldap2.3:
status: Incomplete → Confirmed
Hyuga (hyugaricdeau) wrote :

Ack, I'm glad I'm not the only one to encounter this. I was pulling my hair out thinking it was a problem with my configuration, but couldn't figure out what it could be, since I don't have this problem in Dapper. It just seems to be an issue in Hardy.

If it helps any, I encountered this problem at first through python-ldap. I explicitly set TLS_CACERTDIR to '/etc/ssl/certs' and then call start_tls_s(). This causes a rather unhelpful CONNECT_ERROR exception to be raised. Attached is a Python command line session demonstrating the problem.

When I set TLS_CACERTDIR in my ldap.conf and try using ldapsearch I get the same errors. If I specify a specific certificate file with TLS_CACERT then there's no problem. Likewise in Python.

Mathias Gug (mathiaz) wrote :

This is because the gnutls doesn't support CA certificates stored in a directory (contrary to openssl). Opening a task for the gnutls package.

Changed in openldap:
importance: Undecided → Medium
status: Confirmed → Triaged

The work-around for this in Intrepid was to use "tls_cacert" instead of "tls_cacertdir" in /etc/ldap.conf.

I recently upgraded to jaunty and now the work-around no longer works.

Attached are
1) Output of: ldapsearch -d1 -H ldap://OUR.LDAPSERVER.COM -ZZ -x -D 'uid=SOMEUID,DC=SOME,DC=DOMAIN' -W -b 'OU=People,DC=SOME,DC=DOMAIN'

2) /etc/ldap.conf

FWIW: This same bad behavior is manifest on Jaunty w/OpenLDAP 2.4.15 and libldap-2.4-2.

Abbreviated output of: gnutls-cli --x509cafile /usr/share/ca-certificates/my.crt -p 636 our.ldapserver.com

-----------
Processed 3 CA certificate(s).
Resolving 'our.ldapserver.com'...
Connecting to '127.0.1.1:636'...
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

<snip>

- Peer's certificate is trusted
- Version: TLS1.1
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed
-----------

Abbreviated output of: ldapsearch -x -ZZ -d3 255

-----------
TLS: peer cert untrusted or revoked (0x42)
TLS: can't connect: (unknown error code).
ldap_err2string
ldap_start_tls: Connect error (-11)
-----------

Let me know if I need to supply more information.

It seems the latest release of OpenLDAP addresses these issues. Per the changlog:

OpenLDAP 2.4 Change Log

OpenLDAP 2.4.16 Release (2009/04/05)
 Fixed libldap GnuTLS with x509v1 CA certs (ITS#5992)
 Fixed libldap GnuTLS with CA chains (ITS#5991)
 Fixed libldap GnuTLS TLSVerifyCilent try (ITS#5981)

Perhaps all that is needed is for the new version to be packaged up and placed in the repo?

Hi I'm using the ubuntu 9.10 kernel 2.6.31-21-generic
with the
Package: libldap-2.4-2
State: installed
Automatically installed: no
Version: 2.4.18-0ubuntu1
Priority: important
Section: libs
Maintainer: Ubuntu Developers <email address hidden>
Uncompressed Size: 500k
and the bug continues.
Palliative solution:
When I specify the directory of certificates does not work, but when I specify the certificate in question works.
in /etc/ldap/ldap.conf don't work correctly with TLS_CACERTDIR, try TLS_CACERT /etc/ssl/certs/cert.pem
As authentic by the server ldap, must also change in /etc/ldap.conf

As mentioned earlier in this bug report, the TLS_CACERTDIR configuration directive stopped working when the openldap packages were linked to the GNUTLS library. (At least in the Lucid version, the ldap.conf man page specifcially mentions this issue:
       TLS_CACERTDIR <path>
              Specifies the path of a directory that contains Certifi‐
              cate Authority certificates in separate individual files.
              The TLS_CACERT is always used before TLS_CACERTDIR. This
              parameter is ignored with GNUtls.
)

However, it's worth mentioning that when the Debian/Ubuntu ca-certificates package (or more specificially, the "update-ca-certficates script) uses the user's "enabled certificate" configuration choices to populate the /etc/ssl/certs directory, it also creates a single file, /etc/ssl/certs/ca-certificates.crt, containing all of the trusted certificates that it has processed.

So, if one is trying to just use the standard system-wide list of trusted certificates, changing the old config line from
  TLS_CACERTDIR /etc/ssl/certs
into
  TLS_CACERT /etc/ssl/certs/ca-certificates.crt
should work as desired (with GNUTLS).

(It should be possible to do the same thing in /etc/ldap.conf for the libpam-ldap/libpam-nss packages -- or in /etc/nslcd.conf for the nscld package -- though it seems like you have to spell it "TLS_CACERTFILE" instead of "TLS_CACERT" there.)

Nathan

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnutls26 (Ubuntu):
status: New → Confirmed
Ryan Tandy (rtandy) wrote :

It looks like very recent GnuTLS releases (>= 3.3.6) may have finally added the API needed to make this possible:

https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/

http://gnutls.org/manual/html_node/X509-certificate-API.html#index-gnutls_005fx509_005ftrust_005flist_005fadd_005ftrust_005fdir

No idea whether or not it's as simple as it looks, but I'll have a go at it some time.

Changed in gnutls26 (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers