Comment 1 for bug 397636

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.