[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Last attempt at TLS/SSL

Howard Chu just reminded me of a possibility ... grasping at straws ... are
you putting the OpenLDAP client settings in the OpenLDAP ldap.conf?  I know
I have two separate ldap.conf files that I must keep straight.

The only other thing I can think of is correct path (punctuation esp.) to
the certs as listed in your conf files.

Good luck!


"You don't stop playing because you grow old ...
       you grow old because you stop playing."

Linux Technology Center, Linux Security
tie line:     678-9216
external:  1-512-838-9216
e-mail:  dksoper@us.ibm.com

                      "Lawrence, Mike (White                                                                                         
                      Plains)"                         To:       Kent Soper/Austin/IBM@IBMUS, "Lawrence, Mike (White Plains)"        
                      <Mike.Lawrence@starwoodho         <Mike.Lawrence@starwoodhotels.com>                                           
                      tels.com>                        cc:       openldap-software@OpenLDAP.org,                                     
                      Sent by:                          owner-openldap-software@OpenLDAP.org                                         
                      owner-openldap-software@O        Subject:  RE: Last attempt at TLS/SSL                                         
                      06/26/2003 02:18 PM                                                                                            

Hi Kent - doesn't look like a permissions issue to me
as the CA cert (and all the directories above it, in my
case /var/tmp/certs) are all world readable.

Here is some extra info, all the lines I have turned on
in my slapd.conf file and also ldap.conf:


include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/nis.schema
include         /usr/local/etc/openldap/schema/solaris.schema

pidfile         /usr/local/var/slapd.pid
argsfile        /usr/local/var/slapd.args

loglevel        9

TLSCipherSuite          HIGH:MEDIUM:+SSLv2
TLSCertificateFile      /var/tmp/certs/ldapcert.pem
TLSCertificateKeyFile   /var/tmp/certs/ldapkey.pem
TLSCACertificateFile    /var/tmp/certs/demoCA/cacert.pem
TLSVerifyClient         never

password-hash           {CRYPT}

access to attr=userPassword
        by self write
        by anonymous auth
        by dn.base="cn=Authenticator,dc=webtech,dc=com" read
access to * by * read

database        ldbm
suffix          "dc=webtech,dc=com"
rootdn          "cn=Manager,dc=webtech,dc=com"
rootpw          {crypt}JOEdsf45uddHpilE
directory       /usr/local/var/openldap-data
mode            0600

index   objectClass     eq
index   uid             pres,eq
index   cn              pres,eq


host wp-app-3.webtech.com
base dc=webtech,dc=com
uri ldaps://wp-app-3.webtech.com
binddn cn=Authenticator,dc=webtech,dc=com
bindpw admin123
port 636
scope sub
pam_password crypt
nss_base_passwd         ou=People,dc=webtech,dc=com?one
nss_base_shadow         ou=People,dc=webtech,dc=com?one
ssl yes
TLS_CACERT /var/tmp/certs/demoCA/cacert.pem

I see the same problem if I change over to port 389 and
don't run ldaps, but instead use "ssl start_tls".  Although
when I use that, I can't even get openssl to verify the
cert.  I'm agnostic as to using ldaps or ldap and TLS,
which ever would actually work would be fine.

And I actually have a copy of your how to printed out sitting
on my desk right now that I have been using it as a reference
and am wondering why openldap hates me so much because this
seems like it should be fairly easy to make work.

-----Original Message-----
From: Kent Soper [mailto:dksoper@us.ibm.com]
Sent: Thursday, June 26, 2003 3:00 PM
To: Lawrence, Mike (White Plains)
Cc: openldap-software@OpenLDAP.org; owner-openldap-software@OpenLDAP.org
Subject: Re: Last attempt at TLS/SSL

Hi Mike,

"So there's one piece of software, openssl, saying "your cert is cool".
if I try to run ldapsearch
and pass it -H "ldaps://wp-app-3.webtech.com", it will fail with this

ldap_bind: Can't contact LDAP server (81)
        additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"

I had this same error after I upgraded my versions of OpenLDAP and
Cyrus-SASL recently and did not create new certs that were used in the
previous setup.
Without creating new certs I got around this by copying the server CA cert
to the client box because I was missing the old client CA cert.  On the
client, TLS_REQCERT was "demand" in ldap.conf and a missing CA cert caused
the cert verification to fail.  Even though you state you set the client
and server certs to the same cert, you might have a permission problem on
the client side.  A CA cert should be globally readable anyway.

Check permissions on all certs and keys.
Check all config files (slapd.conf, ldap.conf, and ldaprc/.lpaprc if you
have one) for the set values and for directives that are set (but unlisted)
by default.

If all else fails, give
"http://www.openldap.org/pub/ksoper/OpenLDAP_TLS_howto.html"; a quick read,
especially the configuration section.

"I've tried turning on tls_checkpeer"

I think this is an old and unused directive.  It's not in the OpenLDAP
2.1.21 man pages anymore.


"You don't stop playing because you grow old ...
       you grow old because you stop playing."

Linux Technology Center, Linux Security
tie line:     678-9216
external:  1-512-838-9216
e-mail:  dksoper@us.ibm.com

This electronic message transmission contains information from the Company
that may be proprietary, confidential and/or privileged.
The information is intended only for the use of the individual(s) or entity
named above.  If you are not the intended recipient, be
aware that any disclosure, copying or distribution or use of the contents
of this information is prohibited.  If you have received
this electronic transmission in error, please notify the sender immediately
by replying to the address listed in the "From:" field.