libgnutls13 rejects ldap server's self-signed certificate

Bug #397636 reported by Steve Cayford
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gnutls13 (Ubuntu)
Confirmed
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.

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

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

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

Revision history for this message
Matthew Roy (matthew-royhousehold) wrote :

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

Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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