[Date Prev][Date Next]
RE: problem starting SSL/TLS
Quanah's advice is good- OpenLDAP 2.2.13 has a number of problems, and the
error you're describing really makes me wonder about the build you're
If you want to avoid the hassle of building and maintaining and OpenLDAP
yourself, we have a fine set of tested and supported OpenLDAP binaries
available for RHEL3 and RHEL4 on i686, x86_64, and ia64. They won't
interfere with Redhat's OpenLDAP libraries or binaries, so your support
contract with Redhat remains in force (be sure and turn off their copy of
Check Connexitor Directory Services in the 'Downloads' section of our
website. CDS version 2 is based on OpenLDAP 2.2, and CDS version 3 is based
on OpenLDAP 2.3. CDS Silver version 2 or 3 should be just what you need,
though I recommend version 3.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org [mailto:owner-openldap-
> software@OpenLDAP.org] On Behalf Of Quanah Gibson-Mount
> Sent: Friday, March 10, 2006 11:58 AM
> To: OpenLDAP-software@OpenLDAP.org
> Cc: Karen R McArthur
> Subject: Re: problem starting SSL/TLS
> --On Friday, March 10, 2006 8:10 AM -0500 Karen R McArthur
> <email@example.com> wrote:
> > I have openldap-2.2.13-4 running on redhat ES4. I am able to start and
> > use my ldap server with no problems until I try to start SSL/TLS. I
> > uncomment the lines in slapd.conf for TLS:
> The first thing to do, is dump RedHat's OpenLDAP.
> The second thing to do is either get OpenLDAP 2.2.30 and build it yourself
> (and understand that OpenLDAP 2.2 is a historic release), or go and get
> OpenLDAP 2.3.20, which is the current stable release.
> RedHat is notorious for doing a very poor job of packaging OpenLDAP, and
> keeping releases around that are extremely old. 2.2.13 is quite old at
> this point, and had numerous bugs that were fixed in the next 17 releases.
> There is also at least 2 DOS vulnerabilities in that release of OpenLDAP.
> ># Certificate entries:
> > TLSCipherSuite HIGH:MEDIUM:+SSLv3
> > TLSCACertificateFile /etc/openldap/cacert.pem
> > TLSCertificateFile /etc/openldap/server_cert.pem
> > TLSCertificateKeyFile /etc/openldap/server_cert.pem
> > TLSVerifyClient never
> > Then, my ldap server does not start. I receive the following errors in
> > /var/log/messages:
> > Mar 10 07:51:07 a7470 slapd: sql_select option missing
> > Mar 10 07:51:07 a7470 slapd: auxpropfunc error no mechanism
> > available
> If you make yourself be the user "ldap" can you verify that you can read
> the pem files?
> I note that you are using Kerberos. Will you be doing this for all your
> authorized connections? Note that SASL/GSSAPI already includes doing
> encryption on the wire, which you can enforce in your ACLs. If that is
> case, then there's generally little purpose in also using TLS to encrypt
> the connection.
> This is a really large idletimeout setting... I set mine to 30 seconds.
> ># Certificate entries:
> ># TLSCipherSuite HIGH:MEDIUM:+SSLv3
> ># TLSCACertificateFile /etc/openldap/cacert.pem
> ># TLSCertificateFile /etc/openldap/server_cert.pem
> ># TLSCertificateKeyFile /etc/openldap/server_cert.pem
> ># TLSVerifyClient never
> Does it work without the TLSCipherSuite command?
> Quanah Gibson-Mount
> Principal Software Developer
> ITS/Shared Application Services
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html