SuSE 9.1, OpenLDAP fine as user ldap, OpenLDAP/TLS only works as user root
I'm trying to get OpenLDAP/TLS working on SuSE 9.1. First I got OpenLDAP without TLS working running as user and group ldap. Then I added the necessary lines to slapd.conf for TLS. The user ldap owns all my certificates and the owning group for them is also ldap. If I run slapd as root, OpenLDAP/TLS works fine. If I run it as ldap, I get the following errors, Client: ldap_start_tls: Connect error (-11) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure Server: TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:887 If I remove the TLS stuff from slapd.conf and run slapd as user ldap, it again works fine. Any ideas? Jason Joines =================================
Jason wrote regarding '[SLE] SuSE 9.1, OpenLDAP fine as user ldap, OpenLDAP/TLS only works as user root' on Fri, Oct 08 at 12:36:
I'm trying to get OpenLDAP/TLS working on SuSE 9.1. First I got OpenLDAP without TLS working running as user and group ldap. Then I added the necessary lines to slapd.conf for TLS. The user ldap owns all my certificates and the owning group for them is also ldap. If I run slapd as root, OpenLDAP/TLS works fine. If I run it as ldap, I get the following errors,
Client: ldap_start_tls: Connect error (-11) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Server: TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:887
If I remove the TLS stuff from slapd.conf and run slapd as user ldap, it again works fine. Any ideas?
What about permissions for the directories containg the certs? Are those also readable by ldap:ldap? --Danny, just a thought from someone who's about to fall asleep at his desk
Danny Sauer wrote:
Jason wrote regarding '[SLE] SuSE 9.1, OpenLDAP fine as user ldap, OpenLDAP/TLS only works as user root' on Fri, Oct 08 at 12:36:
I'm trying to get OpenLDAP/TLS working on SuSE 9.1. First I got OpenLDAP without TLS working running as user and group ldap. Then I added the necessary lines to slapd.conf for TLS. The user ldap owns all my certificates and the owning group for them is also ldap. If I run slapd as root, OpenLDAP/TLS works fine. If I run it as ldap, I get the following errors,
Client: ldap_start_tls: Connect error (-11) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Server: TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:887
If I remove the TLS stuff from slapd.conf and run slapd as user ldap, it again works fine. Any ideas?
What about permissions for the directories containg the certs? Are those also readable by ldap:ldap?
--Danny, just a thought from someone who's about to fall asleep at his desk
Yep, everything I can find related to LDAP including the certs and their directory is readable by ldap. Another odd thing, I set up another SuSE 9.1 server with the same versions, same configuration, etc. and it works fine. Only difference is it is running on old hardware as a test server. I'm trying to compare what it has open in lsof versus what the failed one does, then check permissions on all that. So far, it all looks the same.
Jason Joines wrote:
Danny Sauer wrote:
Jason wrote regarding '[SLE] SuSE 9.1, OpenLDAP fine as user ldap, OpenLDAP/TLS only works as user root' on Fri, Oct 08 at 12:36:
I'm trying to get OpenLDAP/TLS working on SuSE 9.1. First I got OpenLDAP without TLS working running as user and group ldap. Then I added the necessary lines to slapd.conf for TLS. The user ldap owns all my certificates and the owning group for them is also ldap. If I run slapd as root, OpenLDAP/TLS works fine. If I run it as ldap, I get the following errors,
Client: ldap_start_tls: Connect error (-11) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Server: TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:887
If I remove the TLS stuff from slapd.conf and run slapd as user ldap, it again works fine. Any ideas?
What about permissions for the directories containg the certs? Are those also readable by ldap:ldap?
--Danny, just a thought from someone who's about to fall asleep at his desk
Yep, everything I can find related to LDAP including the certs and their directory is readable by ldap. Another odd thing, I set up another SuSE 9.1 server with the same versions, same configuration, etc. and it works fine. Only difference is it is running on old hardware as a test server. I'm trying to compare what it has open in lsof versus what the failed one does, then check permissions on all that. So far, it all looks the same.
Now I need to be able to see what files slapd is trying to access at startup. Is there any way to do this? I can use lsof to see everything slapd has open at a particular moment in time but I need something like a continuous operation. Jason ===========
Jason wrote regarding 'Re: [SLE] SuSE 9.1, OpenLDAP fine as user ldap, OpenLDAP/TLS only works as user root' on Fri, Oct 08 at 16:37:
Jason Joines wrote:
Danny Sauer wrote:
Jason wrote regarding '[SLE] SuSE 9.1, OpenLDAP fine as user ldap, OpenLDAP/TLS only works as user root' on Fri, Oct 08 at 12:36:
I'm trying to get OpenLDAP/TLS working on SuSE 9.1. First I got OpenLDAP without TLS working running as user and group ldap. Then I added the necessary lines to slapd.conf for TLS. The user ldap owns all my certificates and the owning group for them is also ldap. If I run slapd as root, OpenLDAP/TLS works fine. If I run it as ldap, I get the following errors,
Client: ldap_start_tls: Connect error (-11) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Server: TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:887
If I remove the TLS stuff from slapd.conf and run slapd as user ldap, it again works fine. Any ideas?
What about permissions for the directories containg the certs? Are those also readable by ldap:ldap?
--Danny, just a thought from someone who's about to fall asleep at his desk
Yep, everything I can find related to LDAP including the certs and their directory is readable by ldap. Another odd thing, I set up another SuSE 9.1 server with the same versions, same configuration, etc. and it works fine. Only difference is it is running on old hardware as a test server. I'm trying to compare what it has open in lsof versus what the failed one does, then check permissions on all that. So far, it all looks the same.
Now I need to be able to see what files slapd is trying to access at startup. Is there any way to do this? I can use lsof to see everything slapd has open at a particular moment in time but I need something like a continuous operation.
I think that bumping up the debug level does this... --Danny, noting that he won't check the list over the weekend :)
Jason Joines wrote:
I'm trying to get OpenLDAP/TLS working on SuSE 9.1. First I got OpenLDAP without TLS working running as user and group ldap. Then I added the necessary lines to slapd.conf for TLS. The user ldap owns all my certificates and the owning group for them is also ldap. If I run slapd as root, OpenLDAP/TLS works fine. If I run it as ldap, I get the following errors,
Client: ldap_start_tls: Connect error (-11) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Server: TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:887
If I remove the TLS stuff from slapd.conf and run slapd as user ldap, it again works fine. Any ideas?
Jason Joines =================================
Appears to me more interesting still. I just noticed that if I run slapd from /etc/init.d/ldap, TLS fails whether I specify user and group of root or user and group of ldap in /etc/sysconfig/ldap. If I run slapd from the command line as root, TLS works fine. If I run slapd from the command line as ldap by prividing -u ldap -g ldap to slapd, TLS fails. If I run slapd from the command line as root and also specify -u root -g root, TLS fails. Seems TLS is failing if -u and -g are used at all regardless of what user and group is specified.
participants (2)
-
Danny Sauer -
Jason Joines