Anyhow, I thought that my experience in trying to get openLDAP 2.0.x working with TLS would be of interest to someone because the solution was so orthogonal it is unbelievable.
I have working OpenLDAP servers with TLS on two other machines so was baffled when I tried /etc/rc.d/init.d/ldap start and got [FAILED] with a very similar configuration to the others. Permissions on the TLS files are very finicky so I tried tweaking those--but nothing was working. I tried strace on the slapd binary but that did not offer any clues. I was able to get it to work by running slapd in debug mode on the command line, but in that mode it was ignoring the -u ldap so was running as root. So that told me there was some sort of permissions problem. But where?
Setting up syslog for openldap (not on by default, unfortunately) indicated these errors in the syslog logfile:
Aug 18 22:07:21 funhouse slapd[29220]: daemon: socket() failed errno=97 (Address family not supported by protocol)
Aug 18 22:07:21 funhouse slapd[29220]: daemon: socket() failed errno=97 (Address family not supported by protocol)
Aug 18 22:07:21 funhouse slapd[29220]: main: TLS init def ctx failed: 0
Aug 18 22:07:21 funhouse slapd[29220]: slapd stopped.
Aug 18 22:07:21 funhouse slapd[29220]: connections_destroy: nothing to destroy.
Hmmm. Not too helpful. I googled on these messages and didn't find a thing that helped. I tried all kinds of permissions tweaking to no avail.
Adding SLAPD_OPTIONS="-d 6" to /etc/sysconfig/ldap offered up these gems of wisdom:
TLS: could not load verify locations (file:`/etc/openldap/ssl/cert/cacert.pem',dir:`').
TLS: error:0200100D:system library:fopen:Permission denied bss_file.c:104
TLS: error:2006D002:BIO routines:BIO_new_file:system lib bss_file.c:106
TLS: error:0E064002:configuration file routines:CONF_load:system lib conf_lib.c:91
TLS: error:0906D06C:PEM routines:PEM_read_bio:no start line pem_lib.c:662
TLS: error:0B084009:x509 certificate routines:X509_load_cert_crl_file:missing asn1 eos by_file.c:284
main: TLS init def ctx failed: 0
slapd shutdown: freeing system resources.
slapd stopped.
connections_destroy: nothing to destroy.
[FAILED]
WTF? So it looks like some permissions problem with /etc/openldap/ssl/cert/cacert.pem. But that file is world-readable. Does openLDAP think that it needs write perms to that file? Okay--wish granted. Nothing.
What finally turned me onto the final solution was the last line "X509_load_cert_crl_file..." The OpenSSL library is trying to find a CRL file. Why would it be having trouble (I don't have a CRL for my CA)? Poking around /usr/share/ssl I noticed that openssl.cnf is not world-readable. Well, I knew that. But most things that need it start as root and then drop privs and it hasn't been a problem. Let's just for the heck of it chmod 644 the file and try again.
# /etc/rc.d/init.d/ldap start
Starting slapd: [ OK ]
You have got to be kidding me?!?! openssl.cnf must be readable by the ldap user! None of the log messages indicated this. You would think that there would be an fopen() call that would fail in trying to open this file... Well, there is. Looking at the strace output I find:
open("/usr/share/ssl/openssl.cnf", O_RDONLY) = -1 EACCES (Permission denied)
getpid() = 11271
getpid() = 11271
getpid() = 11271
getpid() = 11271
open("/etc/openldap/ssl/cert/cacert.pem", O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=3607, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0
x40377000
read(7, "Certificate:\n Data:\n V"..., 4096) = 3607
The fact that openLDAP kept trucking along after failing to open what appears for it to be a critical file diverted attention away from the real reason it would not start!
oh my god,
ReplyDeletei've been battling with the same problem for an hour or so now, it finally came down to a permissions problem with my certs, although not exactly the openssl.cnf problem, they certanly dont make the error message intuitive...
Thanks I've just had this after hacking around with openssl.cnf for multile certificate generation with multiple CNs and AltServerNames.
ReplyDeleteFound you on google :)
Completely agree that error messages weren't helpful
Oh thank you so much for this post! It fixed a very similar problem for me. I chown ldap:ldap all of my LDAP certificates & it magically worked.
ReplyDeleteThis is the first helpful post on this, but it hasn't helped - yet! I learned to use strace today though and found this error:
ReplyDeleteopen("/usr/lib/sasl2/slapd.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
Sure enough, the file doesn't exist. So I touched it and the error is gone, but still no slapd
USlacker:
ReplyDeleteNot sure why slapd would be trying to open slapd.conf in /usr/lib/sasl2 directory. This file is typically in /etc/openldap or /etc/ldap, depending on your distro.
Instead of "touching" the file in that directory, try making a symbolic link to the real slapd.conf file and seeing if that makes a difference. For example:
rm /usr/lib/sasl2/slapd.conf
ln -s /etc/ldap/slapd.conf /usr/lib/sasl2/slapd.conf
And see if openldap starts after that.
Have you tried running slapd with the debug flag -d 6 and looking at the output to see what's up?
I didn't understand it either. All I could guess was that sasl uses a .conf file for app specific config.
ReplyDeleteMore importantly, I found the problem. I had added TLS_CACERT /etc/openldap/cacert.pem
to my ldap.conf file (trying to make phpldapadmin use TLS). While strace didn't report it, as soon as I removed it, slapd started.
Thanks for the help and the lead
I know this is from almost two years ago, but I hit this on Google so other people will, too. If you build your standard slapd with SASL2 support, then it will look in your SASL2 lib dir (usually /usr/lib/sasl2) for a config file that contains SASL2 config directives. This file often shares the name of the process that's looking for it, and has the .conf extension. In other words.../usr/lib/sasl2/slapd.conf. Making a symbolic link to your /etc/ldap/slap.conf in /usr/lib/sasl2 is a bad idea, since this file contains directives for the SASL2 libraries, and not for slapd, as USlacker said.
ReplyDelete