Debian – OpenLDAP with ldaps support on Debian Lenny

I guess you could attack this in one of two ways: getting the ldapsearch client to work using your existing certificates, or generating new certificates that it likes. Personally, I'd imagine modifying your server certificate to be easier than changing the ldapsearch code, so that's what I looked at.

The error above suggests that something is lacking in your server-side certificate (ie the client doesn't want to talk to your server because it's not identifying properly).

For starters, I examined the certificate used by a random LDAP server, in this case directory.washington.edu. If you snag its certificate, eg:

openssl s_client -connect directory.washington.edu:636 > dirwash.crt

and then do:

openssl x509 -in dirwash.crt -text

you'll see:

        X509v3 Key Usage: 
            Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
        X509v3 Extended Key Usage: 
            TLS Web Client Authentication, TLS Web Server Authentication

Other LDAP servers (eg ldap.virginia.edu) don't have those extensions at all. Others, like ldap.itd.umich.edu have a variation of the above:

        X509v3 Key Usage: 
            Digital Signature, Key Encipherment
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication, TLS Web Client Authentication

In short, I suggest that you check your server certificate – post it here if you like – to see whether it contains X509v3 (Extended) Key Usage extensions and, if so, whether those look like ones in use on other LDAP servers.

I saw a mail thread that suggested that either: (1) the extensions should be absent; or (2) if the extensions are present, they need to contain at least TLS Web Server Authentication. I don't know if that's true in this case, but something to consider anyhow.

There are a few possibilities here.

Is the new certificate really valid and verifiable against the issuing CA certificate?

What is the value of the attribute olctlscacertificatefile in your OpenLDAP configuration? In your case it should point to your root CA certificate, the one that signed the server's certificate. The proper value, however, would be /etc/ssl/certs/ca-certificates.crt where all trusted CA certificates are concatenated, yours included. See here for details: http://manpages.ubuntu.com/manpages/precise/man8/update-ca-certificates.8.html

It also could indicate a permission problem. Are the key and certificate (and parent paths) readable by the openldap user? Is the path of the key and certificate such that AppArmor doesn't complain? Check /var/log/kern.log for messages indicating that slapd tried to read a file outside of the paths AppArmor permits.

Edit: As per your updated question, which seems to have nothing to do with the original, it looks like you either messed up permissions in /var/lib/ldap or you really managed to corrupt one or more files in /var/lib/ldap. I say restore from backup.