openldap failing to launch if SSL/TLS enabled. error "main: TLS init def ctx failed: -1" ?
i've installed openldap. starts fine without SSL/TLS.
if SSL/TLS is enabled, slapd fails to launch @ error: "main: TLS init def ctx failed: -1".
googling the issue, suggestions are cert problems. mine, i believe are OK.
any ideas as to what the problem is?
here's what i've done/checks so far:
i've installed openldap from rpm's,
rpm -qa | grep openldap openldap2-back-perl-2.4.11-5.1 openldap2-client-2.4.11-6.1 openldap2-2.4.11-5.1 openldap2-back-meta-2.4.11-5.1
without TLS/SSL, the service starts,
service ldap start Starting ldap-server done
ps ax | grep slapd 6062 ? S<sl 0:00 /usr/lib/openldap/slapd -h ldap:// -f /etc/openldap/slapd.conf -u ldap -g ldap -4 -o slp=on
if i add TLS/SSL config to /etc/openldap/slapd.conf,
... TLSCertificateFile /etc/apache2/ssl.crt/svr.crt TLSCertificateKeyFile /etc/apache2/ssl.key/svr.key TLSCACertificateFile /etc/apache2/ssl.crt/ca.crt TLSCipherSuite TLSv1+HIGH:!aNULL:@STRENGTH TLSVerifyClient never ...
service fails to start,
service ldap start Starting ldap-server failed
and log reports,
Aug 15 10:02:01 auth slapd[6139]: main: TLS init def ctx failed: -1 Aug 15 10:02:01 auth slapd[6139]: slapd destroy: freeing system resources. Aug 15 10:02:01 auth slapd[6139]: slapd stopped. Aug 15 10:02:01 auth slapd[6139]: connections_destroy: nothing to destroy. Aug 15 10:02:01 auth slapd[6139]: daemon: SLPDereg(ldap://) failed with -20, cookie = 0
the certs/keys i'm, using are used in my apache server,
SSLCertificateFile /etc/apache2/ssl.crt/svr.crt SSLCertificateKeyFile /etc/apache2/ssl.key/svr.key SSLCACertificateFile /etc/apache2/ssl.crt/ca.crt SSLCipherSuite TLSv1+HIGH:!aNULL:@STRENGTH SSLVerifyClient none SSLVerifyDepth 1
and SSL works there without problem.
the keys & certs check out ok,
------ openssl rsa -noout -text -in "/etc/apache2/ssl.key/svr.key" Private-Key: (2048 bit) modulus: 00:d2:3e:45:1c:09:10:d2:a1:c6:61:c2:fa:ad:35: ... 23:97 publicExponent: 65537 (0x10001) privateExponent: 00:b0:82:00:e9:69:9f:0b:07:30:93:30:eb:dd:f1: ... 48:01 prime1: 00:ea:8e:ea:13:2c:71:be:3c:68:8b:5e:7a:c8:1e: ... cf:ea:b4:92:2a:e5:14:1c:01 prime2: 00:e5:76:57:25:91:72:eb:ac:19:74:9a:2d:85:65: ... a9:81:b0:7f:b4:f3:f1:9f:97 exponent1: 06:2b:94:44:c4:da:89:22:95:ad:74:e2:cd:f8:dd: ... 62:95:35:73:23:6b:90:01 exponent2: 1a:a4:1f:c0:1b:e0:04:de:c9:61:d1:58:c1:a9:2c: ... 44:e6:72:1d:57:49:51:67 coefficient: 12:11:93:09:34:3e:ae:41:2d:dc:78:f3:11:e0:da: ... 73:80:99:ec:78:b3:4c:90
openssl x509 -noout -text -in "/etc/apache2/ssl.crt/ca.crt" Certificate: Data: Version: 3 (0x2) Serial Number: 12...21 (0x...5d) Signature Algorithm: sha512WithRSAEncryption Issuer: C=US, ST=ST, L=CITY, O=TEST, OU=TEST, CN=TEST_CA Validity Not Before: Aug 15 02:43:41 2008 GMT Not After : Aug 15 02:43:41 2009 GMT Subject: C=US, ST=ST, L=CITY, O=TEST, OU=TEST, CN=TEST_CA Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit): 00:f3:ee:cf:21:bc:49:59:1a:e0:62:5b:df:87:9e: ... 9b:fb:1d Exponent: 65537 (0x10001) X509v3 extensions: Netscape Comment: SS ROOT CA CERT X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 Netscape Cert Type: SSL CA, S/MIME CA X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 3B:...:32 X509v3 Authority Key Identifier: keyid:3B:...:32 DirName:/C=US/ST=ST/L=CITY/O=TEST/OU=TEST/CN=TEST_CA serial:48:...:5D
Signature Algorithm: sha512WithRSAEncryption da:02:bb:96:3a:72:83:73:15:8c:c9:1d:1d:41:47:2c:9e:7b: ... 70:d0:ac:96:09:7d:28:e2
openssl x509 -noout -text -in "/etc/apache2/ssl.crt/svr.crt" Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha512WithRSAEncryption Issuer: C=US, ST=ST, L=CITY, O=TEST, OU=TEST, CN=TEST_CA Validity Not Before: Aug 15 02:49:19 2008 GMT Not After : Aug 15 02:49:19 2009 GMT Subject: C=US, ST=ST, L=CITY, O=TEST, OU=TEST, CN=*.testdomain.net/emailAddress=postmaster@testdomain.net Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d2:3e:45:1c:09:10:d2:a1:c6:61:c2:fa:ad:35: ... 23:97 Exponent: 65537 (0x10001) X509v3 extensions: Netscape Comment: OpenSSL Generated Certificate X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Client, S/MIME, Object Signing X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement X509v3 Extended Key Usage: critical Code Signing, Time Stamping, TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Key Identifier: 00:...:1B X509v3 Authority Key Identifier: keyid:3B:...:32
Signature Algorithm: sha512WithRSAEncryption 5b:56:cb:38:40:62:ae:13:9a:e7:c3:d8:a9:2f:e6:04:fc:32: ... ff:29:74:52:73:28:fa:ca ------
On Fri, 15 Aug 2008, Ben Wailea, openldap-software wrote:
i've installed openldap. starts fine without SSL/TLS.
if SSL/TLS is enabled, slapd fails to launch @ error: "main: TLS init def ctx failed: -1".
Try starting it with -d255 and see what other log messages show up.
Philip Guenther
Philip Guenther wrote:
On Fri, 15 Aug 2008, Ben Wailea, openldap-software wrote:
i've installed openldap. starts fine without SSL/TLS.
if SSL/TLS is enabled, slapd fails to launch @ error: "main: TLS init def ctx failed: -1".
Try starting it with -d255 and see what other log messages show up.
Most likely a file permissions error; he said he's using the same cert/key file as for his Apache server, but most likely the key file is not readable by the ldap user.
On Fri, Aug 15, 2008 at 3:50 PM, Howard Chu hyc@symas.com wrote:
Most likely a file permissions error; he said he's using the same cert/key file as for his Apache server, but most likely the key file is not readable by the ldap user.
msgs crossed in the mail, but seems to be the case.
again, any issues/problems running openldap as ldap:root, or root:root?
or is it 'better' to just make copies of the certs, chown the copies to ldap:ldap, and live with multiple instances?
Ben Wailea, openldap-software wrote:
On Fri, Aug 15, 2008 at 3:50 PM, Howard Chuhyc@symas.com wrote:
Most likely a file permissions error; he said he's using the same cert/key file as for his Apache server, but most likely the key file is not readable by the ldap user.
msgs crossed in the mail, but seems to be the case.
again, any issues/problems running openldap as ldap:root, or root:root?
or is it 'better' to just make copies of the certs, chown the copies to ldap:ldap, and live with multiple instances?
Personally I would put ldap and apache into a group and make the key readable to that specific group.
Howard Chu hyc@symas.com writes:
Ben Wailea, openldap-software wrote:
msgs crossed in the mail, but seems to be the case.
again, any issues/problems running openldap as ldap:root, or root:root?
or is it 'better' to just make copies of the certs, chown the copies to ldap:ldap, and live with multiple instances?
Personally I would put ldap and apache into a group and make the key readable to that specific group.
Debian, for example, handles cert management by creating an ssl-cert group and making private keys of certs in /etc/ssl/certs readable by that group by default, so you can then add the system users for any software that needs to read private SSL keys to the ssl-cert group.
On Fri, Aug 15, 2008 at 5:02 PM, Russ Allbery rra@stanford.edu wrote:
msgs crossed in the mail
again :-/ i need to refresh b4 sending.
Debian, for example, handles cert management by creating an ssl-cert group and making private keys of certs in /etc/ssl/certs readable by that group by default, so you can then add the system users for any software that needs to read private SSL keys to the ssl-cert group.
& that's effectively what i did, but in /usr/local/etc/ssl
next, i'll re-invent fire. the wheel, maybe in Oct ...
On Fri, Aug 15, 2008 at 4:47 PM, Howard Chu hyc@symas.com wrote:
Personally I would put ldap and apache into a group and make the key readable to that specific group.
easy & works like a champ. thanks!
for others' ref:
cat /etc/apache2/uid.conf User wwwrun Group www egrep "OPENLDAP_USER=|OPENLDAP_GROUP=" /etc/sysconfig/openldap OPENLDAP_USER="ldap" OPENLDAP_GROUP="ldap"
groupadd wwwssl grep wwwssl /etc/group usermod -G wwwssl ldap usermod -G wwwssl wwwrun
mkdir -p /usr/local/etc/ssl cd /usr/local/etc/ssl mkdir ssl.crt mkdir ssl.key
cp {.../ca.crt,.../svr.crt} ssl.crt/ cp .../svr.key ssl.key/
chown -R root:wwwssl /usr/local/etc/ssl chmod 755 ssl.crt chmod 750 ssl.key
chmod 644 ssl.crt/ca.crt chmod 644 ssl.crt/svr.crt chmod 640 ssl.key/svr.key
point apache2 & openldap confs as these files.
service apache2 start Starting httpd2 (prefork) done
service ldap start Starting ldap-server done
ps ax | egrep "http|ldap" 8359 ? S<s 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf 8603 ? S<sl 0:00 /usr/lib/openldap/slapd -h ldap:// -f /etc/openldap/slapd.conf -u ldap -g ldap -4 -o slp=on
Howard Chu hyc@symas.com wrote:
Personally I would put ldap and apache into a group and make the key readable to that specific group.
Not that some programs will not accept that: sendmail insiste on the ket being mode 600, for instance. I had to copy the key in a second file.
On Fri, Aug 15, 2008 at 9:07 PM, Emmanuel Dreyfus manu@netbsd.org wrote:
Not that some programs will not accept that: sendmail insiste on the ket being mode 600, for instance. I had to copy the key in a second file.
yeah, i've found the same issue. pita, imho. exim, e.g., handles it nicely in that it allows def'n of separate exec & auth users/groups, so that thte app can run as 'exim', but use other own/perm certs.
atm, not an issue for me though. since i'm implementing this as an auth server in a 'lightweight' Xen VM, it's just openldap + kerberos + apache + openssh. and , it seems, these are ok.
Off-topic; my last post on this.
On Fri, 15 Aug 2008, Ben Wailea, openldap-software wrote:
On Fri, Aug 15, 2008 at 9:07 PM, Emmanuel Dreyfus manu@netbsd.org wrote:
Not that some programs will not accept that: sendmail insiste on the ket being mode 600, for instance. I had to copy the key in a second file.
yeah, i've found the same issue. pita, imho. exim, e.g., handles it nicely in that it allows def'n of separate exec & auth users/groups, so that thte app can run as 'exim', but use other own/perm certs.
In the late 90s, the sendmail mta took a bunch of criticism for permitting insecure configurations. People didn't read the docs and then complained later. So the sendmail developers made it check everything they could think of and refuse everything even slightly dangerous, and then added a config variable to permit the disabling of specific checks. That variable is named "DontBlameSendmail", to remind people before they set it that they're taking things into their own hands and need to obtain their own surety. So the modern result: people don't read the docs and then complain. Plus ça change...
Philip Guenther
openldap-software@openldap.org
-
Ben Wailea, openldap-software -
Howard Chu -
manu＠netbsd.org -
Philip Guenther -
Russ Allbery