Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a Centos 6.3 virtualbox VM snapshot with LDAPS (openldap) set up. I've set up it few days ago following tips from different sources and wrote down everything afterwards. But when I try to repeat installation (following my own instructions), I fail to do that: SSL handshake is dropped as if the server has completely misconfigured SSL certificates. It looks like if I've pointed server config to non-existent certificate file. I'm running all checks locally (using ldapsearch and "openssl s_client"). To make things even worse, LDAPS at my snapshot stops working with the same issue after reboot. Restarting slapd/nslcd/nscd services without reboot does not break it 0_o Copying exact configs and certs to clean (without LDAPS set up) snapshot of the same VM and proper configuration does not work. That's why the issue seems to be not related to configuration and certificates. I've spent digging more than 10 hours, but still have a strong wish to understand the cause.

It's principal (educational) for me to understand why does this issue occur only after reboot and not after service restart. Please feel free to post any ideas of things that are reset to default/smashed/messed up when Linux host reboots. In other words, in what way system reboot may differ from service restart in scope of a separate service captured in a VM snapshot?

I've already checked:

  • Of course, logs/netstat/ps
  • a tmp directory (it's cleaned at every reboot, but does not contain any related files)
  • environment variables
  • date (at snapshot, date is wrong. Fixing date and restarting services does not break LDAPS)
  • hostname/ip (I'm using manually assigned IP for this instance. After reboot and restoring network settings, I tried to restart services with no success)
  • service arguments and slapd.args file at /var/run directory
  • writing garbage into config files of a service and restarting it to see if exactly this file is used.
  • /etc/env / .bashrc / .bash_aliases files have NOT been modified and should not interfere.

Maybe SELinux is a cause (maybe it was disabled at snapshot, will check it tomorrow at work)

Any other suggestions? Too tired to fight further today...

share|improve this question

2 Answers 2

SSL connections failing is often caused by the time being out of sync. VM's tend to do that, so make sure you run ntpd on all your VM's and that an ntpdate is run at boot before ntpd starts.

share|improve this answer
Good point, faced that few times, but not my case - I've already checked that – Dmitriusan Jul 16 '13 at 22:22
up vote 1 down vote accepted

The issue was really caused by SELinux in a complicated way.

For future people who will find this answer via google, here is an exact error text:

[root@va21 ~]# ldapsearch -d 1 -v -x -H ldaps://localhost:636
ldap_initialize( ldaps://localhost:636/??base )
ldap_new_connection 1 1 0
ldap_connect_to_host: TCP localhost:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)'                 certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/openldap/certs prefix .
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

and openssl s_client output:

[root@va21 ~]# openssl s_client -connect localhost:636 -showcerts
140066435413832:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake     failure:s23_lib.c:184:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 113 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

It means (it should mean!) that ssl certificates are not available/readable/accessible/valid when slapd server starts up.

I was preparing VM image for QA testing of some application. This application disables SELinux during setup. So I've had SELinux disabled during configuration of openldap, and had no any issues when placed certificates to /certs folder.

My troubles started when I had to deploy openldap with the same configuration to a clean VM or reboot an existing one. SELinux was enabled here, and it prevented slapd from reading certificates from not allowed place. Service logs or output did not contain any clear complaint about permission denial. I should place certificates somewhere to /etc/ssl/certs/ and /etc/openldap/certs to make it work.

share|improve this answer

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.