Just getting back to this. I recreated my certificate and key and now
my ldaps connections work. I think it had to do with the fact that I
answered no to two questions from the gnutls certtool when I created my
certificate. It asked if:
1. Whether this certificate will be used for a TLS server, and
2. Whether this certificate will be used to encrypt data
I recreated my certificate and key and answered yes to those two
questions and now ldaps connections are working.
On 01/30/2014 11:43 AM, Warron S French wrote:
Low Sensitivity/Aerospace Internal Use Only
Low Sensitivity/Aerospace Internal Use Only
Joshua, were you able to get TLS configured and your clients were
specifically Debian? I ask, because my clients were CentOS which is
downstream from Red Hat.
Try using ldapmodify with -v and -d ## set along with the other
arguments and syntax; do you still see no more verbosity? I did, I
wonder if you will see what I discovered.
I ran the following command:
*/ldapmodify -x -D "cn=admin,cn=config" -W -d 32768 -f
/tmp/LDAP-CONFIG-TLS.ldif/*
However, I was also running */slapd /*with */-d 32768/* as an argument
as well. I don't know if it makes any difference, but I was not using
GnuTLS, but OpenSSL.
*Warron French, MBA, SCSA*
From: Joshua Schaeffer <[email protected]>
To: c chupela <[email protected]>,
Cc: "[email protected]" <[email protected]>
Date: 01/30/2014 12:05 PM
Subject: Re: Antw: problem with accessing secure ldap
Sent by: [email protected]
------------------------------------------------------------------------
I think I'm running into this right now. I just setup ldaps a couple
days ago, but I can't get any of my clients to connect to it. I can
see my openldap server listening on port 636 and I can telnet to that
server and port from another machine successfully, but I still get
this error:
ldap_sasl_bin(SIMPLE): Can't contact LDAP server (-1)
the verbose option doesn't give me much more useful information than
that. I have a hunch that it has to do with the certificates, but I'm
using GnuTLS as I'm on Debian and the slapd package since lenny is
only compiled against GnuTLS. What was the command you ran to get
this output?
On Thu, Jan 30, 2014 at 9:09 AM, c chupela <[email protected]_
<mailto:[email protected]>> wrote:
further troubleshooting on my part with ldapsearch/debugging turned
up, gave me the following:
TLS: certdb config: configDir='/etc/openldap/certs'
tokenDescription='ldap(0)' certPrefix=" keyPrefix=" flags=readOnly
TLS: using moznss security dire /etc/openldap/certs prefix
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errono 21 - moznss
error -5938
TLS: can't connect: TLS error -5938:Encountered end of file
ldap_err2string
ldap_sasl_bin(SIMPLE): Can't contact LDAP server (-1)
searches I;ve done on this error seem to point to certificate/openSSL
problems.
Anyone run into this before?
On Friday, January 24, 2014 5:39 PM, c chupela <[email protected]_
<mailto:[email protected]>> wrote:
After having some packet traces done, what was revealed is that from a
windows client running the softerra ldap browser, we could see the
connection be established between client and server (syn, ack synack)
client requests sending of data, and server resets/closes the
connection, never sending any data, as I also saw with attempting to
telnet to port 636 - connection is closed by remote host.
Regarding the question of is TLS enabled, if I understand the doc
correctly, the answer is yes. With respect to the TLS_REQCERT never
statement, I believe it was set this way because this was only
intended to be a testing server.
contents of ldap.conf:
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=plandb,dc=stuff,dc=acme,dc=com
URI ldap://_plandb-qa.stuff.acme.com_
<http://plandb-qa.stuff.acme.com/>ldaps://_plandb-qa.stuff.acme.com:636_
<http://plandb-qa.stuff.acme.com:636/>
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
TLS_CACERTDIR /etc/openldap/certs
TLS_REQCERT never
currently running slapd process:
1 S ldap 5603 1 0 80 0 - 111440 futex_ Jan21 ? 00:00:02
/usr/sbin/slapd -h ldap:/// ldaps:/// ldapi:/// -u ldap
On Thursday, January 23, 2014 3:25 AM, Ulrich Windl
<[email protected]_
<mailto:[email protected]>> wrote:
>>> c chupela <[email protected]_ <mailto:[email protected]>>
schrieb am 22.01.2014 um 18:43 in Nachricht
<[email protected]_
<mailto:[email protected]>>:
> I've been tasked with figuring out why a redhat 6.4 server
w/openldap v2.4.23
> is not accessible.
> This server is a test server. I have a production server that is
working
> properly, and I've gone thru and compared config files, etc, but
haven't
> found any differences.
>
> I'm a newbie with this, so my understanding is still somewhat limited.
> Here's what I've done or checked so far:
>
> - iptables is not running
> - if I run netstat, I can see port 389/port 636 in listening state:
>
> tcp 0 0 _0.0.0.0:636_ <http://0.0.0.0:636/>
0.0.0.0:*
> LISTEN 5603/slapd
> tcp 0 0 _0.0.0.0:389_ <http://0.0.0.0:389/>
0.0.0.0:*
> LISTEN 5603/slapd
> tcp 0 0 :::636 :::*
> LISTEN 5603/slapd
> tcp 0 0 :::389 :::*
> LISTEN 5603/slapd
>
> I can telnet to port 389 on this server from another server, but not
to port
> 636 - putty will throw back an immediate 'connection closed by
remote host'
> message.
>
> I'm not seeing any slapd related messages in /var/log/messages.
>
> What else can I check on here?
Syslog
>
> Thanks
> Chris
Low Sensitivity/Aerospace Internal Use Only
Low Sensitivity/Aerospace Internal Use Only
