Akke Bengtsson wrote:

Is it still a requirement that TLS keys must have their password nullified before using them in an openldap context?

Basically yes, though as you note below, newer OpenSSL versions can prompt you for a password as needed.

Some experimentation with slapd startup has revealed that for some combinations of OS and OpenLDAP version, I will be given a prompt for the TLS password and can also input it and the slapd daemon starts correctly. On other systems, I was prompted for the password but before I even could enter it, the slapd startup crashed. The tests were all performed doing a manual startup via "/etc/init.d/ldap start". Automatic startup means that the password, instead of being entered by a person, has to reside on file and thereby be accessible to potential intruders.

Is there any way to prevent unprotected keys or passwords to keys in this context?

No really good ideas come to mind. I have a patch for libldap to explicitly set a callback to supply the key password, it won't make it into 2.4.13 but probably will be in 2.4.14. I will probably add two options to slapd, analogous to the back-bdb options to set the DB encryption key. (One option to set the key directly as an argument of the config option, one option to read the key from an arbitrary file.) Obviously for automated startup the plaintext of the key must be accessible to the slapd somewhere, and that means it is also accessible to potential intruders. This is just a fact of life. You can make key retrieval more tedious by hiding it behind other layers of encryption, but ultimately the keys to each of those layers must also be accessible, otherwise slapd itself cannot use them.

There are "clever" schemes to hide startup keys, but they tend to make restarts difficult. E.g., store keys on a mountpoint that you remount some other filesystem onto after the boot sequence has completed and all dependent daemons have started. Keep a file handle open on the new filesystem, to prevent it from being dismounted without rebooting the system. It'll fool a lot of intruders, but you won't be able to restart individual daemons without rebooting the machine.

Akke Bengtsson