Ubuntu

libgnutls13 rejects ldap server's self-signed certificate

Reported by Steve Cayford on 2009-07-09
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gnutls13 (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: libgnutls13

Description: Ubuntu 8.04.3 LTS
Release: 8.04

I have a machine running Ubuntu hardy which uses a remote ldap server for authentication and has been working smoothly for about two years now. Today, after upgrading libgnutls13 from 2.0.4-1ubuntu2.3 to 2.0.4-1ubuntu2.5 all the ldap queries failed. It appeared that gnutls was rejecting the self-signed certificate presented by the ldap server.

/var/log/auth.log reported these errors: "nscd: nss_ldap: could not search LDAP server - Server is unavailable"

The log on the ldap server showed incoming connections which then immediately would unbind again.

Doing a standalone ldapsearch against the server resulted in the error: "TLS: peer cert untrusted or revoked (0x42)."

After downgrading libgnutls13 back to version 2.0.4-1ubuntu2.3 the ldap queries succeeded and users could once again login to the system. Note, however, that a standalone ldapsearch still gives the error message above.

Scott Briggs (scott-br) wrote :

So the latest update (2.5 from 2.3) completely breaks our ldap infrastructure which relies on a self created CA to sign all of our internal certs. I'm still trying to figure out what the specific cause is, but this is definitely the source of the problem - as soon as I upgrade to 2.5, I can no longer use ldap authentication and just as quickly, I can use ldap as soon as I downgrade to 2.3.

From the ldap server logs:
Jul 14 00:17:17 ldapserver slapd[29785]: conn=14112697 fd=214 ACCEPT from IP=X.X.X.X:37919 (IP=0.0.0.0:636)
Jul 14 00:17:17 ldapserver slapd[29785]: conn=14112697 fd=214 TLS established tls_ssf=256 ssf=256
Jul 14 00:17:17 ldapserver slapd[29785]: conn=14112697 fd=214 closed (connection lost)

On the client side with a simple "ldapsearch -x -v" (the ldap.conf file has the URI and specific cipher suite) I get this:
ldap_initialize( <DEFAULT> )
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

My guess is that this has something to do with how I originally set up our ldap infrastructure - because of the extremely poorly documented switch from openssl to gnutls in debian/ubuntu's implementation of openldap, I set a specific TLSCipherSuite with strong encryption. Setting the cipher suite to a generic "high encryption" which incorporated a number of specific cipher suites no longer worked.

Also, why was this only now pushed to hardy-updates when it was built in feb? I have servers I built only last week that don't even have this update.

Kastus (kastus) wrote :

Just wanted to confirm the same behavior here. After installing 2.0.4-1ubuntu2.5 LDAP authentication broke immediately. Although I was able to run ldapsearch command without experiencing any problems. We are using LDAP server on RHEL3u6 and certificate is self-signed I believe. Rollback to 2.0.4-1ubuntu2.3 fixed the problem.

We have close to 150 servers authenticating against LDAP, a mixture of CentOS/Ubuntu/RHEL and none of them has any problems connecting to LDAP servers using TLS. I think 2.0.4-1ubuntu2.5 should be fixed or at least withdrawn.

Thanks, -Kastus

Pavel Lisy (pavel-lisy) wrote :

Just wanted to confirm the same behavior here.

Description: Ubuntu 8.04.4 LTS
Release: 8.04

The same problem is in 2.0.4-1ubuntu2.6
workaround is disabling to require and verify the server certificate
in /etc/ldap.conf set:
tls_checkpeer no

see: man nss_ldap

Pavel

You can also work around this by copying over the CA certificate you're using (even if self-signed) and pointing to it with a line like "TLS_CACERT /etc/ssl/certs/cacert.pem" into /etc/ldap/ldap.conf for ldap-utils

Since 9.04(?) I've been using libnss-ldapd and libpam-ldapd, which also need the cacert pointed out in /etc/nslcd.conf:
# SSL options
ssl on
tls_reqcert demand
tls_cacertfile /etc/ssl/certs/cacert.pem

Launchpad Janitor (janitor) wrote :

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

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

Other bug subscribers