On 01/11/2013 08:27 AM, Arvind Navale wrote:
Hi There,
Need help with resolving an configuration issue I am having with openldap server (OpenLDAP: slapd 2.4.23 (Jun 22 2012 14:02:53) ) running a CentOS-6.3
- Have a openldap server setup with TLS running on CentOS-6.3
rpm -qa | grep ldap openldap-devel-2.4.23-26.el6.x86_64 python-ldap-2.3.10-1.el6.x86_64 apr-util-ldap-1.3.9-3.el6_0.1.x86_64 openldap-servers-2.4.23-26.el6.x86_64 openldap-2.4.23-26.el6.x86_64 openldap-clients-2.4.23-26.el6.x86_64 pam_ldap-185-11.el6.x86_64 ldapjdk-4.18-6.el6.x86_64
- Have generated self signed server certificates using openssl command.
openssl req -x509 -nodes -days 3650 -newkey rsa:1048 -keyout /etc/openldap/certs/server-key.pem -out /etc/openldap/certs/server-cert.pem
- Have a CentOS-6.3 setup a openldap client and enable TLS.
rpm -qa | grep ldap openldap-2.4.23-26.el6.x86_64 python-ldap-2.3.10-1.el6.x86_64 openldap-clients-2.4.23-26.el6.x86_64 apr-util-ldap-1.3.9-3.el6_0.1.x86_64 pam_ldap-185-11.el6.x86_64
- When I try to login on a LDAP client, I am seeing following
debugging messages in LDAP server side,
slap_listener(ldaps://:389/)
daemon: listen=7, new connection on 14 daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: epoll: listen=9 active_threads=0 tvp=NULL daemon: epoll: listen=10 active_threads=0 tvp=NULL daemon: added 14r (active) listener=(nil) conn=1000 fd=14 ACCEPT from IP=xxx.xxx.xxx.xxxx:55585 (IP=0.0.0.0:389) daemon: activity on 2 descriptors daemon: activity on: 14r daemon: read active on 14 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: epoll: listen=9 active_threads=0 tvp=NULL daemon: epoll: listen=10 active_threads=0 tvp=NULL connection_get(14) connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 TLS: file server-cert.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping. TLS: file server-key.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping. TLS: error: no server certificate: must specify a certificate for the server to use TLS: error: could not initialize moznss security context - error -5939:No more entries in the directory TLS: can't create ssl handle. connection_read(14): TLS accept failure error=-1 id=1000, closing connection_closing: readying conn=1000 sd=14 for close connection_close: conn=1000 sd=14
- I generate the hash in the directory were the certs are and then
try connecting again, see different slapd debugging messages
Did you restart slapd after fixing the cert hashes?
conn=1001 fd=14 ACCEPT from IP=10.90.180.220:55586 (IP=0.0.0.0:389) daemon: activity on 1 descriptor daemon: activity on: 14r daemon: read active on 14 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: epoll: listen=9 active_threads=0 tvp=NULL daemon: epoll: listen=10 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: epoll: listen=9 active_threads=0 tvp=NULL daemon: epoll: listen=10 active_threads=0 tvp=NULL connection_get(14) connection_get(14): got connid=1001 connection_read(14): checking for input on id=1001 TLS: error: could not initialize moznss security context - error -5925:The one-time function was previously called and failed. Its error code is no longer available TLS: can't create ssl handle. connection_read(14): TLS accept failure error=-1 id=1001, closing connection_closing: readying conn=1001 sd=14 for close connection_close: conn=1001 sd=14 daemon: removing 14 daemon: activity on 1 descriptor daemon: activity on: conn=1001 fd=14 closed (TLS negotiation failure)
Is there any bug with the version of openldap I am using? Appreciate any and every help from any of the group member to resolve the issue.
Thank you, anlinux.