[Date Prev][Date Next]
RE: Last attempt at TLS/SSL
OK, now the two ldap.conf files are seperate, thanks to Kent
and Howard for picking up on that as a potential issue. I had
been sym linking one file to another, so they were definitely
mixed in together. Now that I have them seperate, I've made
some progress but I am still not there 100% yet. It looks
like I have the ldap.conf file set up correctly now to do
ldapsearches. What I mean by this is the ldap.conf file that
is in /usr/local/etc/openldap. When I use these settings, it
is finally working with my cert:
BASE dc=webtech, dc=com
Also I can now authenticate through telnet and those sessions
look encrypted when I "snoop" them, so I am also going to chalk
that up to the /usr/local/etc/openldap/ldap.conf file being OK
now and telnet making use of it. Also I made sure the native
solaris ldap client config files didn't exist and that its
ldap cache manager is off. This is all using ldaps, I am not
using start_tls; I only run slapd on port 636.
However, the other part of the equation is to get ssh to work
with the pam_ldap module. So that should be using padl's
ldap.conf file which is in /etc. For this one, I am still
seeing TLS errors like this:
Jun 30 11:00:46 wp-app-3.webtech.com slapd: [ID 733216 local4.debug]
connection_read(8): TLS accept error error=-1 id
In the /etc/ldap.conf file, here is what I have:
I have tried tweaking here ad infinitum with no success. If
anyone specifically has any advice for this config file since
it seems to be the last thing that is still broken it would be
extremely welcome. I've changed the lines "ssl true",
"tls_checkpeer", "tls_cacertfile", "tls_ciphers", etc, over
and over in various ways/combinations and this just won't work.
It seems to me that either having tls_checkpeer off, or having
it on and supplying the cacert.pem file should make this the
same as the "other" ldap.conf file in terms of how it decides
the cert is OK, so I'm puzzled as to why it's broken.
Also are there any suggestions as to other replacement pam and nss
ldap modules for Solaris other than padl's?
Thanks - Michael
From: Howard Chu [mailto:email@example.com]
Sent: Thursday, June 26, 2003 3:59 PM
To: 'Lawrence, Mike (White Plains)'; 'Kent Soper'
Cc: openldap-software@OpenLDAP.org; owner-openldap-software@OpenLDAP.org
Subject: RE: Last attempt at TLS/SSL
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Lawrence, Mike
> 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:
> 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
You have PADL directives and OpenLDAP directives mixed together in the same
file. This sometimes works, but I recommend keeping them separate, to
Don't use "host" and "port" directives with "uri" - just use one or the
other. It's preferable to only use the "uri" directive. That also removes
need for the "ssl" directive, since all of this information is present in
> 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.
It's not OpenLDAP's fault that you're mixing config info for two separate
packages together and getting poor results.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
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.