ldap tls refusing to initialize

[PeterNSteinmetz]

Binary package hint: libldap-2.4-2

Trying to run a slapd server in Ubuntu 9.04, generally following the docs at: https://help.ubuntu.com/9.04/serverguide/C/openldap-server.html.

It works fine until I try and use certificates as per the section TLS and SSL on that page.

Then, if I try and start using /etc/init.d/slapd it tells me to start using the debugging flags. If I then do so with the command:
sudo slapd -d -1 -h 'ldap:/// ldapi:/// ldaps:///' -g openldap -u openldap -F /etc/ldap/slapd.d/

At the end of copious output is:

main: TLS init def ctx failed: -1
slapd destroy: freeing system resources.
slapd stopped.

This is with entries in /etc/ldap/slapd.d/cn=config.ldif like:

olcTLSCACertificateFile: /home/peter/CA/server-ca-cert.pem
olcTLSCertificateFile: /home/peter/CA/server-gnutls-cert.pem
olcTLSCertificateKeyFile: /home/peter/CA/server-gnutls-key.pem

If these entries are commented out, the server will start and work.

This occurs with a private key and certificate generated using both openssl and with the gnutls certtool.

Dependencies for slapd are:

ldd -v $(which slapd)
        linux-gate.so.1 => (0xb7de2000)
        libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0xb7d97000)
        liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0xb7d89000)
        libdb-4.7.so => /usr/lib/libdb-4.7.so (0xb7c34000)
        libodbc.so.1 => /usr/lib/libodbc.so.1 (0xb7bcd000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7bb4000)
        libslp.so.1 => /usr/lib/libslp.so.1 (0xb7ba4000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7b8b000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7b73000)
        libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb7ad5000)
        libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7ac3000)
        libz.so.1 => /lib/libz.so.1 (0xb7aad000)
        libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb7a44000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7a12000)
        libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb79fb000)
        libltdl.so.7 => /usr/lib/libltdl.so.7 (0xb79f2000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb79ee000)
        libwrap.so.0 => /lib/libwrap.so.0 (0xb79e5000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7882000)
        /lib/ld-linux.so.2 (0xb7de3000)
        libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb787e000)

Related packages installed:
gnutls-bin 2.4.2-6ubuntu0.1 gnutls26 install ok installed
gnutls-doc 2.4.2-6ubuntu0.1 gnutls26 install ok installed
ldap-utils 2.4.15-1ubuntu3 openldap install ok installed
libcurl3-gnutls 7.18.2-8ubuntu4.1 curl install ok installed
libgnutls26 2.4.2-6ubuntu0.1 gnutls26 install ok installed
libldap-2.4-2 2.4.15-1ubuntu3 openldap install ok installed
slapd 2.4.15-1ubuntu3 openldap install ok installed

It doesn't seem like this could be a problem with V1 certificates, since both the CA cert and the server cert have X.509 Certificate Information: Version: 3 (cf. https://bugs.launchpad.net/bugs/305264).
Additionally they have Signature Algorithm: RSA-SHA.

I wonder if it is related to a cipher suite specification, given http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256. Though I tried setting 'olcTLSCipherSuite: +AES-256-CBC:+SHA1' in the cn=config.ldif file, to no avail.

I don't know how to get the more detailed information from TLS, I only see the 'main: TLS init def ctx failed: -1' line.

Is this another issue with the gnutls specifications? Or just something missing in the docs there for jaunty. Strikes me as a fairly important issue for ubuntu server.

Peter

[Mathias Gug (mathiaz)]

On Fri, Aug 28, 2009 at 02:38:46AM -0000, PeterNSteinmetz wrote:
> At the end of copious output is:
>
> main: TLS init def ctx failed: -1
> slapd destroy: freeing system resources.
> slapd stopped.
>
> This is with entries in /etc/ldap/slapd.d/cn=config.ldif like:
>
> olcTLSCACertificateFile: /home/peter/CA/server-ca-cert.pem
> olcTLSCertificateFile: /home/peter/CA/server-gnutls-cert.pem
> olcTLSCertificateKeyFile: /home/peter/CA/server-gnutls-key.pem
>

You're using a non-standard location for your certificates. Thus slapd
apparmor profile needs to be updated.

See https://wiki.ubuntu.com/DebuggingApparmor for more information.

  status invalid

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

[PeterNSteinmetz (ndoc2)]

Thanks Mr. Gug. I checked this, placing the apparmor profile into complain mode with sudo aa-complain /usr/sbin/slapd.

The same problem occurs with an attempt to start slapd, but there are no entries in /var/log/kern.log associated and no audit entries.

I also moved the certificates and keys generated using gnutls into /etc/ssl/certs and /etc/ssl/private. Still the same problem with no audit entries in the /var/log/kern.log.

I'm not quite certain what is meant by standard locations, since https://help.ubuntu.com/9.04/serverguide/C/openldap-server.html says to put then in /etc/ssl/certs and /etc/ssl/private under the TLS and SSL sections, though I am happy to try moving them anywhere that may help.

Is there some setting I should be using to get more information out of gnutls about what may be going on?

thanks,
Peter

[Christian Roessner (christian-roessner-net)]

I do confirm this.

And: Howard Chu still explains NOT TO USE GNUTLS with openldap! It is broken by design! Do not wonder for strange behavior, if you do not trust the core developers.

http://www.openldap.org/lists/openldap-devel/200802/msg00072.html

I have asked Howard a couple of days ago and he still stays at his opinion. I think Debian/Ubuntu should not make changes from openssl to gnutls!

For this bug:

...
1.2.36.79672281.1.13.3 (rdnMatch): 2.5.13.1 (distinguishedNameMatch): matchingRuleUse: ( 2.5.13.1 NAME 'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $ subschemaSubentry $ entryDN $ namingContexts $ aliasedObjectName $ dynamicSubtrees $ distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $ olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcAccessLogDB $ member $ owner $ roleOccupant $ manager $ documentAuthor $ secretary $ associatedName $ dITRedirect ) )
    2.5.13.0 (objectIdentifierMatch): matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) )
TLS: gcry_control GCRYCTL_SET_RNDEGD_SOCKET failed
main: TLS init failed: 0
slapd destroy: freeing system resources.
slapd stopped.
connections_destroy: nothing to destroy.

And by the way: My certs are under /ca/ldapmaster.roessner-net.com

My profile for apparmor was working under intrepid. Upgrading from intrepid to jaunty does not work.

# Last Modified: Tue Sep 2 13:08:01 2008
# Author: Jamie Strandboge <email address hidden>

#include <tunables/global>
/usr/sbin/slapd flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/ssl_certs>

  capability dac_override,
  capability net_bind_service,
  capability setgid,
  capability setuid,

  /ca/cacert_org.crt r,
  /ca/ldapmaster.roessner-net.de/newcert.pem r,
  /ca/ldapmaster.roessner-net.de/newkey.pem r,
  /etc/gai.conf r,
  /etc/hosts.allow r,
  /etc/hosts.deny r,
  /etc/ldap/ldap.conf r,
  /etc/ldap/schema/* r,
  /etc/ldap/slapd.conf r,
  /etc/sasldb2 r,
  /etc/ssl/private/ r,
  /etc/ssl/private/* r,
  /usr/lib/ldap/ r,
  /usr/lib/ldap/* mr,
  /usr/sbin/slapd mr,
  /var/lib/ldap/ r,
  /var/lib/ldap/* rw,
  /var/lib/ldap-ov/accesslog r,
  /var/lib/ldap-ov/accesslog/* rw,
  /var/lib/ldap/alock kw,
  /var/lib/ldap-ov/accesslog/alock kw,
  /var/run/slapd/* w,
}

No dmesg output that points to problems.

[PeterNSteinmetz (ndoc2)]

Interesting that there is the TLS complaint through "TLS: gcry_control ..."

Nothing like that in mine. I was looking through the source a bit last night on this. It seems that the TLS init call is returning a -1 error code under some circumstances without really throwing another error message.

Despite the problems with gnutls, it seems the ubuntu folks are committed to staying with it for licensing reasons.

[Christian Roessner (christian-roessner-net)]

Ok, I finally got it work. I had purged slapd completely and removed all
of its /var/lib/ldap/* stuff as well as the slapd.d directory
under /etc/ldap.

After that I tried to install slapd. Same error! So I really wondered
how a fresh install could present me with the same error message,
although there was absolutely no TLS support, yet. And then I got it: I
had a look inside /etc/ldap/ldap.conf, which was the only file left from
the previous installation:

TLS_RANDFILE /dev/urandom

was the problem. I simply removed this tag. Then I put back my saved
backup from intrepid (including overlays and TLS support), started slapd
and now everything is working as expected. So my guess is that this
option is broken under jaunty. It is unnecessary, because the man page
tells that /dev[u]random is looked automatically. But this got broken
from intrepid to jaunty.

[PeterNSteinmetz (ndoc2)]

Interesting. My version also was an upgrade from hardy->intrepid->jaunty. My /etc/ldap/ldap.conf doesn't contain a line about TLS_RANDFILE though, and my install doesn't report the TLS: gcry_control error, rather, there is nothing other than the "main: TLS init def ctx failed: -1" complaint. I suspect these may be related problems, at least in the sense of hard to tell what is going wrong during initialization.

I will likely later this weekend try to clear aside configuration and try a local build of openldap with debugging for gdb turned on and built against gnutls.

[MatthiasK (mkubik)]

Same here. I have a vanilla Januty install (Atom-330 with 64-bit Januty, if this makes any difference) and following the above instructions that Peter referenced fails for me with the same error and my ldap.conf also doesn't have this TLS_RANDFILE set.

[PeterNSteinmetz (ndoc2)]

Playing around with the source today and debugging slapd with gdb.

It appears that much of the pain here is in tls_g.c, the wrappers for gnutls. The function tlsg_ctx_init in particular. This is where, at least for my configuration, most of the failures are occurring. And the code in this function often makes a call onto a gnutls function, as in:

 if (lo->ldo_tls_cacertfile != NULL) {
  rc = gnutls_certificate_set_x509_trust_file(
   ctx->cred,
   lt->lt_cacertfile,
   GNUTLS_X509_FMT_PEM );
  if ( rc < 0 ) return -1;
 }

and doesn't really do anything with the return code. There are 3 places in tlsg_ctx_init where this occurs with no logging of what the actual error code was. It just returns -1, rather than a more specific error code. Upshot is that we simply get a -1 error code in the log with no further advice on the specific problem.

The code in tls_o.c for this function and others seems better developed and reports more useful error codes.

With a self-signed certificate, and setting only the olcTLSCertificateFile
olcTLSCertificateKeyFile, the server works and does answer properly when trying with a command on another machine like:

openssl s_client -connect <ldapServerIP>:636 -showcerts

If oldTLSCACertificateFile is set to the self-signed certificate, slapd fails to initialize TLS.

I suspect most of the problems being reported are due to configuration issues, like those reported by Christian R. Without better error output, it is very difficult to figure these out.

Now I'd be delighted to try and add more debugging and produce a patch; however, perhaps I can get a bit of help with the packaging?

I've been able to get the source with 'apt-get source libldap-2.4-2', and go in change the debian/configure.options, followed by a 'debchange -i' and 'debuild -us -uc -i -I', then a 'sudo debi', and get a version with debugging symbols installed.

What has been eluding me (after reading the HOWTO and several other tutorials), is how to get changes in the source to build into the package properly when installed and how to get other Debug statements to work (though perhaps that is just because the packaging isn't working right, since the machine language statements in the debugger don't agree with the source listed in gdb, ouch). With a -nc option on debuild it builds, but likely isn't actually including the changes. Without the -nc, it complains about the upstream patches not being able to be applied.

Hopefully someone can point me to the correct descriptions or give me some help on this one.

Of course, a fixed up package with better error output from one of the openldap gurus would be most welcome!

thanks,
Peter

[Dave Vree (hdave)]

In the meantime, does anybody have a work-around for this? I've hit this problem on a vanilla Ubuntu 9.04 server install and can't get past it!

[PeterNSteinmetz (ndoc2)]

Yes, continues to be annoying.

One thing to do is to carefully verify the certificate chain you have configured for LDAP use. If the certificate is self-signed, then don't configure the olcCACertificateFile item. Otherwise, make sure the CA signing the certificate has its certificate in this property.

[Dave Vree (hdave)]

Well, after much pain and suffering for me it turned out to be a simple permissions problem. I believe the how-to should be changed to ensure this doesn't happen to anyone else. Problem was that my private keyfile did not provide read permissions to the group.

sudo chmod g+r /etc/ssl/private/myserver.key

and viola...everything works.

[PeterNSteinmetz (ndoc2)]

Thanks Dave. I agree about the docs on this. Can you comment on which howto you were using?

[Dave Vree (hdave)]

I was using the how-to referenced by the OP. I was also using this one on certificates.

https://help.ubuntu.com/9.04/serverguide/C/certificates-and-security.html

What got me messed up was a small, but important point that got lost between the two how-tos. The LDAP how-to takes advantage of the group ssl-cert which has read privileges on /etc/ssl/private. They had the nifty idea of putting the openldap account into the ssc-cert group.

The certificate how-to says to put the key into the /etc/ssl/private. This is fine, but while the /etc/ssl/private folder was readable by openldap, the new copied keyfile was not. Unfortunately for me (and probably others) the only error I got was the one the OP was also getting.

A trick I discovered can help:

become root: sudo -i
become openldap: su openldap
check priviledges: cat /etc/ssl/private/nameofmyserver.key

It helped me track down the answer.

[PeterNSteinmetz (ndoc2)]

For the time being, I posted an update for the network-auth.xml in ubuntu-docs.

https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/437483

[Mathias Gug (mathiaz)]

Marking this bug as invalid - seems that most of the issues reported here are configuration issues: file permissions, apparmor profile, certifcates chain.