2

I have a Debian 6.0.5 server running openldap. It appears to be compiled against gnutls. I used gnutls' certtool to generate a self-signed certificate and I have used it on a few debian client machines to authenticate against the openldap server.

However, when I try to do the same on a CentOS 6 client, I get the following error for ldapsearch:

ldap_initialize( <DEFAULT> )    
ldap_start_tls: Can't contact LDAP server (-1)
additional info: TLS error -8101:Certificate type not approved for application.    
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

If I run gnutls-cli-debug on the CentOS client, I get the following:

gnutls-cli-debug -p 636 ldap.blahblah.com
    Resolving 'ldap.blahblah.com'...
    Connecting to '10.6.0.11:636'...
    Error in %INITIAL_SAFE_RENEGOTIATION
    Checking for Safe renegotiation support...

And that's it - it dies.

Has anyone been able to do ldaps in this kind of a setup, gnutls linked server, gnutls generated certificate, openssl linked client?

Thanks!

quanta
  • 51,413
  • 19
  • 159
  • 217
OJD
  • 21
  • 1
  • 2
  • Try 389DS from EPEL repo. Actually, as LDAP I like it more, but couldn't make SSL work despite it's nice interface :D – GioMac Aug 21 '12 at 06:58

1 Answers1

2

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.

fission
  • 3,601
  • 2
  • 21
  • 31