TLS_CACERTDIR not supported in gnutls

Bug #242313 reported by Laurent Pinchart
78
This bug affects 13 people
Affects Status Importance Assigned to Milestone
gnutls26 (Ubuntu)
Invalid
Undecided
Unassigned
openldap (Ubuntu)
Triaged
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.

Revision history for this message
Chuck Short (zulcss) wrote :

Can you try the version from hardy-updates?

Thanks
chuck

Changed in openldap2.3:
status: New → Incomplete
Revision history for this message
Laurent Pinchart (laurent-pinchart-skynet) wrote :

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.

Revision history for this message
Chuck Short (zulcss) wrote :

Please include the log file when this happens

Thanks
chuck

Revision history for this message
Laurent Pinchart (laurent-pinchart-skynet) wrote :

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)

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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
Revision history for this message
allpoints (ubug-allpointsconsulting) wrote :

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

Revision history for this message
allpoints (ubug-allpointsconsulting) wrote :
Revision history for this message
Christopher Nighswonger (cnighswonger) wrote :

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.

Revision history for this message
Christopher Nighswonger (cnighswonger) wrote :

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?

Revision history for this message
Artur Lopes Bezerra (artur-lopes-bezerra) wrote :

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

Revision history for this message
Nathan Stratton Treadway (nathanst) wrote :

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

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

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

Changed in gnutls26 (Ubuntu):
status: New → Confirmed
Revision history for this message
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  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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