Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm pulling my hair out over ldap playing well with SSL/TLS. I can confirm that the server is listening AND responding on port 636 to SSL request. openssl s_client -connect freia.fqdn:636 -showcerts produces expected output, gnutls-cli-debug -p636 localhost produces this. The server has been built from source since the version from ubuntu's repositories had some erronous configs and weren't completing installation. Server is being run with the command slapd -d -1 -h 'ldap:/// ldaps:///' Snipped bootup log here. ldapsearch -H ldap:/// also produces expected output.

ldapsearch -H ldaps:/// 


ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

ldapsearch -Z -H ldaps:/// 


ldap_start_tls: Can't contact LDAP server (-1)
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

The server log says:

TLS trace: SSL_accept:before/accept initialization
tls_read: want=11, got=0

TLS: can't accept: (unknown)

Since it wasn't being sent anything, i checked what ldapsearch was really sending. It says it can't find the pem file

TLS: could not load verify locations (file:`/etc/ssl/private/freia_slapd_key.pem',dir:`').

Which is complete nonsense according to strace ldapsearch -Z -H ldaps:/// -d -1:

open("/etc/ssl/private/freia_slapd_key.pem", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0440, st_size=883, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb770b000
read(4, "-----BEGIN RSA PRIVATE KEY-----\n"..., 4096) = 883
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0xb770b000, 4096)                = 0
write(2, "TLS: could not load verify locat"..., 91TLS: could not load verify locations (file:`/etc/ssl/private/freia_slapd_key.pem',dir:`').

All certs are readable (or should be)

-rw-r--r-- 1 root root 1082 2011-12-26 16:50 /etc/ssl/certs/cacert.pem
-rw-r--r-- 1 root root 1013 2011-12-26 16:51 /etc/ssl/certs/freia_slapd_cert.pem
-r--r----- 1 root root  883 2011-12-26 16:50 /etc/ssl/private/freia_slapd_key.pem

Any ideas at all would be greatly appreciated! Cheers. Slapd.conf and ldap.conf

share|improve this question
up vote 1 down vote accepted

Problem is in ldap.conf:

TLS_CACERT /etc/ssl/private/freia_slapd_key.pem

You use the private key where you should have used the root certificate. In general case, replace it with the proper CA certificate(s) - the certificates that ldapsearch can use as trusted "roots" to confirm all of the other ("untrusted") certificates it meets on the way.

If your /etc/ssl/certs/freia_slapd_cert.pem (not /etc/ssl/private/freia_slapd_key.pem) is self-signed, it means it is a root for itself and you can/should use it as TLS_CACERT. But it means it would be never trusted by the general public, which uses known "roots" (CAs like Verisign, etc) instead.

By the way, TLS_KEY and TLS_CERT are (rightfully) ignored when placed in your system-wide ldap.conf. See

share|improve this answer
Made changes accordingly, restarted slapd server, nothing was fixed as far as I could tell :/ – EricR Dec 27 '11 at 16:44
Is ldapsearch still reading *_key.pem instead of *_cert.pem? – kubanczyk Dec 27 '11 at 16:50
Sigh. Thank you so much. That solved it upon some further inspection. – EricR Dec 27 '11 at 18:43

Your Answer


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.