Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Ubuntu ldap authentication is not working on my client with ssl start_tls option enabled in the ldap.conf file. I can authenticate when I comment out ssl start_tls.

I upgraded the ldap servers certificate and since then users cannot authenticate on my ubuntu 10.04 client machine anymore if ssl is enabled. The changes that occurred:

Cert upgraded from 1024 to 2048 bit
now is a wildcart cert and use it to be a self-signed cert
encryption algorithm is now shaw512 (use to be md5)

My auth.log has some errors:

nss-ldap: do_open: do_start_tls failed:stat=-1

The new certs are working because I have some other clients that authenticate using the new certs (old centOS machines).

Anyone have any ideas why I cannot use ssl anymore with ldap on my client?

share|improve this question

1 Answer 1

Is there a signing hierarchy (i.e not self-signed)? "wildcard" and "self-signed" are not exclusive. A commercial wildcard cert will have a hierarchy, i.e. one or more intermediate CAs, and a root CA.

sha-512 or md5 are hashes used in the cert signature, they are not encryption algorithms. These are used to verify the cert integrity, the cipher used for a connection is negotiated independently of this.

I think the most likely causes are either sha512 (more correctly, "sha512WithRSAEncryption") is not supported in Ubuntu 10; or the machine is missing one or more CA certs (intermediate or root), so full chain verification cannot complete.

You can see if openssl can deal with the server's new cert by running (on the Ubuntu 10 machine):

openssl x509 -in newservercert.crt -noout -text

though that may not be conclusive. This may also be helpful:

ldapsearch -x -Z -v -h your.ldap.server

(There's a slim chance GnuTLS is used instead of OpenSSL, can't help there, sorry!)

You can probably confirm or deny a chain problem by adding this to your /etc/ldap/ldap.conf file:

TLS_REQCERT never

If that helps, you should obtain the missing parts of the chain, and add them to your local store, how that is accomplished depends on the client configuration, checking for "TLS_CACERT" and/or TLS_CACERTDIR in /etc/ldap/ldap.conf directives is where you start.

Less likely causes include:

  • inability to check CRLs (check ldap.conf to see if it's enabled)

And assuming nothing else has changed, improbable causes included for completeness:

  • server protocol version or cipher set unsupported by client
  • change in supported SASL mechanisms
share|improve this answer
    
Are you sure you have the correct certs? AFAICT you're running starttls on port 389, if you are running on port 636 also then try: openssl s_client -connect your.ldap.server:636 -showcerts If you have ldapsearch, what does the ldapsearch command above say? –  mr.spuratic Jan 14 '13 at 19:09
    
Thanks for your response. I tried the 'openssl' command and it read the certificate and I expected 2048 bit key but it has 1024 and the signature algorithm is sha1WithRSAEncryption and I expected sha512WithRSAEncryption. Turns out the shaw512 is the encryption algorithm used on the passwords not on the signature algorithm. Doesn't really matter because this is a working cert on some of my other machines. The ldapsearch command gave me an error: 'ldap_start_tls: Connect error (-11)'. Oh and I was able to get ssl start_tls working if I set 'tls_checkpeer no'. –  admiles Jan 14 '13 at 19:11
    
It's the correct cert because I use the same one on my other clients. Yes the port is 389 and ldapsearch gives the 'ldap_start_tls: Connect error (-11)' error. At least I am using ssl now, better than before, but its a mystery why it won't take my cert. –  admiles Jan 14 '13 at 19:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.