[Pkg-openldap-devel] Bug#381788: slapd: TLS connections fail when running as non-root

Michael Berg michaeljberg at gmail.com
Sun Aug 6 23:10:24 UTC 2006


Package: slapd
Version: 2.3.25-1
Severity: normal

I've had this problem in both slapd 2.3.24-2 and 2.3.25-1.
When slapd is running as root, everything works perfectly.  But when running
as a non-root user (like the new default "openldap"), TLS connections fail.
This effects both port 389+starttls and port 636.

When slapd is running as root, the command
"openssl s_client -connect 127.0.0.1:636 -CAfile /etc/ssl/certs/mydomain.dyndns.org_CA.pem"
successfully establishes a TLSv1 connection to the SSL/TLS port.

When slapd is running as the "openldap" user and group,
the same command produces the following:
==========
CONNECTED(00000003)
depth=1 /C=US/O=mydomain/OU=Certificate Authority/L=MyCity/ST=MyState/CN=mydomain.dyndns.org
verify return:1
depth=0 /C=US/O=mydomain/OU=LDAP Server/L=MyCity/ST=MyState/CN=ldap.mydomain.dyndns.org
verify return:1
1878:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1057:SSL alert number 40
1878:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
==========


ldapsearch and most other packages on my system are configured to use port 389+starttls
==========
$ ldapsearch -x -ZZ

ldap_start_tls: Connect error (-11)
        additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
==========
(This same command succeeds when slapd is running as root)


Just to make sure slapd is working:
==========
$ ldapsearch -x

# search result
search: 2
result: 13 Confidentiality required
text: confidentiality required

# numResponses: 1
==========
(which shows that slapd is running, and is requiring confidentiality as configured)


And if I disable the requirement for confidentiality in slapd.conf,
"ldapsearch -x" successfully returns everything that is should from the LDAP database.


I've made sure that everything listed in slapd's README.Debian.gz for
"Running slapd under a different uid/gid" holds true.
 - openldap user and group are present in the system passwd/group files
	$ getent passwd openldap
	openldap:x:100:121:OpenLDAP Server Account,,,:/var/lib/ldap:/bin/false
	$getent group openldap
	openldap:x:121:
 - SLAPD_USER and SLAPD_GROUP are both set to "openldap" in /etc/default/slapd.
 - /var/lib/ldap and all files in it have user:group of openldap:openldap.
 - Permissions and user:group on slapd.conf have been set to
	-rw-r----- root:openldap
 - Permissions and user:group on /var/run/slapd are
	drwxr-xr-x openldap:openldap

The SSL/TLS private cert is in a location readable by the openldap user and group.
The SSL/TLS public cert is in a location readable by everyone on the system.


The TLS-relevant portions of my slapd.conf are
==========
# TLS configuration
TLSCipherSuite		HIGH:!ADH
TLSCACertificateFile	/etc/ssl/certs/mydomain.dyndns.org_CA.pem
TLSCertificateFile	/etc/ssl/certs/ldap.mydomain.dyndns.org.pem
TLSCertificateKeyFile	/etc/ldap/private/ldap.mydomain.dyndns.org.pem
TLSCRLCheck		none
TLSVerifyClient		never
# Require at least 128 bit encryption for all operations
security	ssf=128
==========


And just for completeness, here are the contents of my ldap.conf file that
ldap clients use
==========
BASE	dc=mydomain,dc=dyndns,dc=org
URI	ldap://ldap.mydomain.dyndns.org
TLS_CIPHER_SUITE	HIGH:!ADH
TLS_CACERT		/etc/ssl/certs/mydomain.dyndns.org_CA.pem
TLS_REQCERT		demand
TLS_CRLCHECK		none
==========


I even tried purging slapd, reinstalling it, and re-populating it from scratch
(I didn't just reload a DB backup).

The fresh install worked fine as non-root until a reboot - at which point the
problem described above returned and TLS connections fail.

I've tried running slapd with various debug levels and with strace - looking for
problems opening any files or other errors, but if it's in there, I'm not seeing it.


Several of the search results for "error:14094410:SSL" mention client certificates,
but I've specified "TLSVerifyClient never" in slapd.conf and it still doesn't explain
why this behavior only shows up when running as non-root.

If there is any specific debug output (slapd -d, strace, ltrace, gdb, etc) you need
to help diagnose the cause, just let me know and I'd by happy to provide it.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.7-amd64-k8-smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages slapd depends on:
ii  adduser                 3.96             Add and remove users and groups
ii  coreutils               5.97-3           The GNU core utilities
ii  debconf [debconf-2.0]   1.5.3            Debian configuration management sy
ii  libc6                   2.3.6-18         GNU C Library: Shared libraries
ii  libdb4.2                4.2.52+dfsg-1    Berkeley v4.2 Database Libraries [
ii  libiodbc2               3.52.4-3         iODBC Driver Manager
ii  libldap-2.3-0           2.3.25-1         OpenLDAP libraries
ii  libltdl3                1.5.22-4         A system independent dlopen wrappe
ii  libperl5.8              5.8.8-6          Shared Perl library
ii  libsasl2                2.1.19.dfsg1-0.2 Authentication abstraction library
ii  libslp1                 1.2.1-5          OpenSLP libraries
ii  libssl0.9.8             0.9.8b-2         SSL shared libraries
ii  libwrap0                7.6.dbs-9        Wietse Venema's TCP wrappers libra
ii  perl [libmime-base64-pe 5.8.8-6          Larry Wall's Practical Extraction 
ii  psmisc                  22.2-1           Utilities that use the proc filesy

Versions of packages slapd recommends:
ii  db4.2-util              4.2.52+dfsg-1    Berkeley v4.2 Database Utilities
ii  libsasl2-modules        2.1.19.dfsg1-0.2 Pluggable Authentication Modules f

-- debconf information:
  slapd/password_mismatch:
  slapd/fix_directory: true
  slapd/invalid_config: true
  slapd/upgrade_slapcat_failure:
  slapd/upgrade_slapadd_failure:
  slapd/backend: BDB
  slapd/dump_database: when needed
* slapd/allow_ldap_v2: false
* slapd/no_configuration: false
  slapd/migrate_ldbm_to_bdb: true
  slapd/move_old_database: true
  slapd/suffix_change: false
  slapd/slave_databases_require_updateref:
  slapd/dump_database_destdir: /var/backups/slapd-VERSION
  slapd/autoconf_modules: true
  slapd/purge_database: false




More information about the Pkg-openldap-devel mailing list