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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
