Help! OpenLDAP won’t start

slapd[5472]: main: TLS init def ctx failed: -1

I borrowed some information from here: https://apple.stackexchange.com/questions/107130/slapd-daemon-cant-start-tls-init-def-ctx-failed-1. Basically, just run slapd -d1 and see where the certificate is having trouble.

Crazily, before I bothered to check that, I just wiped my entire ldap server and rebuilt it. What’s even crazier is that after reinstalling, it never started either! Using CentOS 7, I removed the openldap-servers package and deleted the /var/lib/ldap and /etc/openldap directories. Installing the rpms recreated those directories, but did not rebuild the self-signed certificates in /etc/openldap/certs. I ended up finding this: 0006945: CentOS 6.5: /etc/openldap/certs/* missing – CentOS Bug Tracker. I guess there’s a post-script that should be running when the openssl-servers package gets installed, /usr/libexec/openldap/create-certdb.sh. By running it, it did create some certificates, but those didn’t allow the ldap server to start either.

Finally, I disabled SSL to fix it. These were the steps.

  1. Edit the /etc/openldap/slapd.d/cn/=config.ldif file. Remove anything that starts with olcTLS. There should be only a couple of lines.
  2. Then stop the server from starting in TLS. You may or may not need to do this. In /etc/sysconfig/slapd, if you have ldaps:///, you can remove that part so that the server won’t start in TLS.
  3. Finally, when you’re done with that, the LDAP server will start.

If you want to re-enable the TLS, you can follow these instructions to do it. Configure OpenLDAP over SSL/TLS [Step-by-Step] Rocky Linux 8 | GoLinuxCloud

You can also potentially run into this problem with SELinux or AppArmor. With Ubuntu and AppArmor, here’s how to get around it. https://askubuntu.com/questions/499164/slapd-tls-not-working-apparmor-errors

Hope this helps you!

Use update-ca-trust! Or update-ca-certificates.

Don’t just append the /etc/ssl/certs/ca-certificates.crt or the /etc/ssl/certs/ca-bundle.crt.

Not long ago, I thought that it didn’t matter. I figured since the update-ca-trust command just updated the bundle, I might as well skip a step and go directly. I was wrong. Don’t do it. I guess that’s why people actually have processes and directions to follow.

The files are not meant to be edited manually. They are generated by the update-ca-trust or update-ca-certificates commands, which scan the /etc/pki/ca-trust/source/anchors or /usr/local/share/ca-certificates directories for custom CAs, and then concatenate them with the system CAs into a single file. If you edit these files directly, your changes will be overwritten the next time these commands are run. This could mean that your changes would not survive a patching if the ca-certificates package is updated.

The reason why you want to put the certificate issuers in /etc/pki/ca-trust/source/anchors/ or /etc/ssl/certs/ and use the update-ca-trust enable/extract commands is so that it can survive an update. If someone decides to patch the machine and there are other certificates being updated, the one that you appended to the bundle will get deleted.

Follow the process! For me, that’s basically:

1. Copy your custom CA file (in PEM format) to the /etc/pki/ca-trust/source/anchors directory on Red Hat-based systems, or the /usr/local/share/ca-certificates directory on Debian-based systems. Make sure the file has a .crt extension.
2. Run the update-ca-trust or update-ca-certificates command as root. This will regenerate the /etc/ssl/certs/ca-certificates.crt or the /etc/ssl/certs/ca-bundle.crt file with your custom CA included.
3. Restart any services or applications that use SSL/TLS connections, such as web servers, browsers, curl, etc. They should now trust your custom CA.

Installing Openssl/Openssh on Solaris 8

Installing Openssl/Openssh on Solaris 8

Some Compiling NOTES
– If you have problems and decide to start over, run “echo $?” after each command to see if you have errors in your steps
– If you get an error “Cannot find ELF”, it may be because you are using the gnu strip (from binutils). Use the strip that comes with Solaris in /usr/ccs/bin

1) Install compiler (gcc or equivalent – I used Forte Developer 7). You can install gcc with packages SUNWgcmn and SUNWgcc from the Solaris Companion CD or you can get it from sunfreeware.com.

2) path set – cc and make in your path
ie: PATH=/opt/sfw/bin:/usr/ccs/bin:$PATH
The “make” binary is /usr/ccs/bin and if you got gcc from the companion cd, it will be in /opt/sfw/bin (if you got it from sunfreeware.com, it will be in /usr/local/bin)

3) Install patch 112438-01 (reboot the machine after install)

4) Install Openssl (from openssl.org) – latest version as of this writing is 0.96g.
./Config
make
make install

5) Install Openssh (openssh.org) – latest version as of this writing is 3.4p1 – I’m configuring it with pam (so that I can authenticate via ldap) and xauth (so that I can do XForwarding)
./configure –with-pam –with-xauth=/usr/openwin/bin/xauth
make
make install

6) Create a user for ssh
useradd -g nobody -s ‘/usr/bin/false’ sshd

7) If you want XForwarding, in /usr/local/etc/sshd_config, set:
X11Forwarding yes

8) Start the SSH server
/usr/local/sbin/sshd

9) You may want a script to start the ssh server. This is a modified version of the one I took from a source I can’t remember:

#!/sbin/sh
#
# Init file for OpenSSH server daemon
RETVAL=0
prog=”sshd”

# Some functions to make the below more readable
KEYGEN=/usr/local/bin/ssh-keygen
SSHD=/usr/local/sbin/sshd
RSA1_KEY=/usr/local/etc/ssh_host_key
RSA_KEY=/usr/local/etc/ssh_host_rsa_key
DSA_KEY=/usr/local/etc/ssh_host_dsa_key
PID_FILE=/var/run/sshd.pid

do_rsa1_keygen() {
if [ ! -s $RSA1_KEY ]; then
echo -n $”Generating SSH1 RSA host key: ”
if $KEYGEN -q -t rsa1 -f $RSA1_KEY -C ” -N ” >&/dev/null; then
chmod 600 $RSA1_KEY
chmod 644 $RSA1_KEY.pub
success $”RSA1 key generation”
echo
else
failure $”RSA1 key generation”
echo
exit 1
fi
fi
}

do_rsa_keygen() {
if [ ! -s $RSA_KEY ]; then
echo -n $”Generating SSH2 RSA host key: ”
if $KEYGEN -q -t rsa -f $RSA_KEY -C ” -N ” >&/dev/null; then
chmod 600 $RSA_KEY
chmod 644 $RSA_KEY.pub
success $”RSA key generation”
echo
else
failure $”RSA key generation”
echo
exit 1
fi
fi
}

do_dsa_keygen() {
if [ ! -s $DSA_KEY ]; then
echo -n $”Generating SSH2 DSA host key: ”
if $KEYGEN -q -t dsa -f $DSA_KEY -C ” -N ” >&/dev/null; then
chmod 600 $DSA_KEY
chmod 644 $DSA_KEY.pub
success $”DSA key generation”
echo
else
failure $”DSA key generation”
echo
exit 1
fi
fi
}

do_restart_sanity_check()
{
$SSHD -t
RETVAL=$?
if [ ! “$RETVAL” = 0 ]; then
failure $”Configuration file or keys are invalid”
echo
fi
}

start()
{
# Create keys if necessary
do_rsa1_keygen
do_rsa_keygen
do_dsa_keygen

echo -n $”Starting $prog:”
$SSHD
RETVAL=$?
# [ “$RETVAL” = 0 ] && touch /var/lock/subsys/sshd
echo
}

stop()
{
echo -n $”Stopping $prog:”
pkill $SSHD
RETVAL=$?
# [ “$RETVAL” = 0 ] && rm -f /var/lock/subsys/sshd
echo
}

reload()
{
echo -n $”Reloading $prog:”
killproc $SSHD -HUP
RETVAL=$?
echo
}

case “$1” in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
reload)
reload
;;
condrestart)
if [ “$RETVAL” = 0 ] ; then
stop
# avoid race
sleep 3
start
fi
# fi
;;
status)
status $SSHD
RETVAL=$?
;;
*)
echo $”Usage: $0 {start|stop|restart|reload|condrestart|status}”
RETVAL=1
esac
exit $RETVAL

Apache SSL Self-Signed Certificates Without Passphrase

taken from: http://www.rpatrick.com/tech/makecert/

Following is a quick listing of the commands you need to use when setting up an SSL key for Apache that doesn’t require a passphrase to be entered during normal operations, and includes a self-signed certificate so you needn’t bother with cert requests and CAs. The sequence of events is to create a 3DES key, remove the passphrase, and then generate a self-signed certificate.

The following commands are to be entered via the command line, with each openssl statement requiring interactive input. Performed on Red Hat Linux, these instructions ought to also work on other flavors of Unix with OpenSSL and Apache installed.

openssl genrsa -des3 -out pass.key 1024
openssl rsa -in pass.key -out server.key
openssl req -new -key server.key -x509 -out server.crt -days 999

cp server.key /etc/httpd/conf/ssl.key/
cp server.crt /etc/httpd/conf/ssl.crt/

apachectl restart

Verifying that Apache has the correct SSL directives and is using the correct key and certificate created above is left as an exercise for the webmaster.

If your system has a Makefile or symlink in the Apache conf directory, you can opt to pursue an earlier method to this madness using the below steps (provided here only for completeness):

cd /etc/httpd/conf
/usr/bin/openssl genrsa 1024 > /etc/httpd/conf/ssl.key/server.key
chmod go-rwx /etc/httpd/conf/ssl.key/server.key
make testcert

Optionally, if you need a server.pem file for a given application, such as courier-imapd, use the following to create the .pem file from the previously created certificate and key:

cat server.key server.crt >server.pem

Using the above method you can enjoy the encryption protection provided by SSL without having to pay a commercial vendor to sign your server keys. If you don’t like the popup presented by some applications (e.g. web browsers) about an untrusted certificate, simply follow the process provided by your application to import or install the certificate, at which point you will no longer have to deal with future dialog boxes regarding an untrusted site.