7:53 p.m.
I am trying to get OpenLDAP (2.4.24) working with NSS on Fedora 15. In
cn=config.ldif I have:
olcTLSCACertificatePath: /etc/pki/nssdb
olcTLSCertificateFile: endoframe
I have used certutil to create a self-signed certificate:
# certutil -d /etc/pki/nssdb -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
endoframe Cu,Cu,Cu
But this doesn't appear to be working:
$ ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_close_socket: 3
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_close_socket: 3
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
slapd is running:
# systemctl status slapd.service
slapd.service - LSB: starts and stopd OpenLDAP server daemon
Loaded: loaded (/etc/rc.d/init.d/slapd)
Active: active (running) since Wed, 05 Oct 2011 02:24:11 -0400; 3 weeks and 0
days ago
Main PID: 1429 (slapd)
CGroup: name=systemd:/system/slapd.service
└ 1429 /usr/sbin/slapd -h ldap:/// -u ldap
Any ideas of what I might be doing wrong, or where I should be looking
to debug this?
--
Braden McDaniel <braden(a)endoframe.com>
8:28 p.m.
On 26/10/11 22:53 -0400, Braden McDaniel wrote:
I am trying to get OpenLDAP (2.4.24) working with NSS on Fedora 15.
In
cn=config.ldif I have:
olcTLSCACertificatePath: /etc/pki/nssdb
olcTLSCertificateFile: endoframe
I have used certutil to create a self-signed certificate:
# certutil -d /etc/pki/nssdb -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
endoframe Cu,Cu,Cu
But this doesn't appear to be working:
$ ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_close_socket: 3
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_close_socket: 3
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
slapd is running:
# systemctl status slapd.service
slapd.service - LSB: starts and stopd OpenLDAP server daemon
Loaded: loaded (/etc/rc.d/init.d/slapd)
Active: active (running) since Wed, 05 Oct 2011 02:24:11 -0400; 3 weeks and 0
days ago
Main PID: 1429 (slapd)
CGroup: name=systemd:/system/slapd.service
└ 1429 /usr/sbin/slapd -h ldap:/// -u ldap
Any ideas of what I might be doing wrong, or where I should be looking
to debug this?
slapd was not started with the proper options to listen on ldaps:/// (port
636).
Your -h command line option should include it, e.g. '-h ldap:///
ldaps:///'. See slapd(8) for more details.
--
Dan White
7:23 a.m.
On 11-10-26 11:28 PM, Dan White wrote:
On 26/10/11 22:53 -0400, Braden McDaniel wrote:
> I am trying to get OpenLDAP (2.4.24) working with NSS on Fedora 15. In
> cn=config.ldif I have:
>
> olcTLSCACertificatePath: /etc/pki/nssdb
> olcTLSCertificateFile: endoframe
>
> I have used certutil to create a self-signed certificate:
>
> # certutil -d /etc/pki/nssdb -L
>
> Certificate Nickname
> Trust Attributes
>
> SSL,S/MIME,JAR/XPI
>
> endoframe
> Cu,Cu,Cu
>
> But this doesn't appear to be working:
>
> $ ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
> ldap_url_parse_ext(ldaps://rail)
> ldap_create
> ldap_url_parse_ext(ldaps://rail:636/??base)
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP rail:636
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying ::1 636
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> ldap_close_socket: 3
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying 127.0.0.1:636
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> ldap_close_socket: 3
> ldap_err2string
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>
> slapd is running:
>
> # systemctl status slapd.service
> slapd.service - LSB: starts and stopd OpenLDAP server daemon
> Loaded: loaded (/etc/rc.d/init.d/slapd)
> Active: active (running) since Wed, 05 Oct 2011 02:24:11
> -0400; 3 weeks and 0 days ago
> Main PID: 1429 (slapd)
> CGroup: name=systemd:/system/slapd.service
> └ 1429 /usr/sbin/slapd -h ldap:/// -u ldap
>
> Any ideas of what I might be doing wrong, or where I should be looking
> to debug this?
slapd was not started with the proper options to listen on ldaps:///
(port
636).
Your -h command line option should include it, e.g. '-h ldap:///
ldaps:///'. See slapd(8) for more details.
There is a control file on Fedora 15 for ldaps or tls
cat /etc/sysconfig/ldap
# Options of slapd (see man slapd)
#SLAPD_OPTIONS=
# At least one of SLAPD_LDAP, SLAPD_LDAPI and SLAPD_LDAPS must be set to
'yes'!
#
# Run slapd with -h "... ldap:/// ..."
# yes/no, default: yes
#SLAPD_LDAP=yes
# Run slapd with -h "... ldapi:/// ..."
# yes/no, default: no
#SLAPD_LDAPI=no
# Run slapd with -h "... ldaps:/// ..."
# yes/no, default: no
#SLAPD_LDAPS=no
SLAPD_LDAPS=yes
# Run slapd with -h "... $SLAPD_URLS ..."
# This option could be used instead of previous three ones, but:
# - it doesn't overwrite settings of $SLAPD_LDAP, $SLAPD_LDAPS and
$SLAPD_LDAPI options
# - it isn't overwritten by settings of $SLAPD_LDAP, $SLAPD_LDAPS and
$SLAPD_LDAPI options
# example: SLAPD_URLS="ldapi:///var/lib/ldap_root/ldapi ldapi:/// ldaps:///"
# default: empty
#SLAPD_URLS=""
# Maximum allowed time to wait for slapd shutdown on 'service ldap stop'
(in seconds)
#SLAPD_SHUTDOWN_TIMEOUT=3
# Parameters to ulimit, use to change system limits for slapd
#SLAPD_ULIMIT_SETTINGS=""
1:04 p.m.
Tail –f /var/log/messages
Has most of the ldap messages,
You also may have a :
/var/log/localmessages
If you are running a client on the server machine, the client info will be
mixed in with the server info on
/var/log/messages.
I believe you will only get the server [slapd] on localmessages
You have to choose either ldap [port 389] with tls,
Or
Ldaps [port 636]
I am assuming you have a tls_cacert and either a uri with ldap://... Or
ldaps://
As appropriate, in /etc/ldap.conf of the client machine.
On 10/27/11 10:23 AM, "Daniel Qian" <daniel(a)up247solution.com> wrote:
On 11-10-26 11:28 PM, Dan White wrote:
> On 26/10/11 22:53 -0400, Braden McDaniel wrote:
>
>> I am trying to get OpenLDAP (2.4.24) working with NSS on Fedora 15. In
>> cn=config.ldif I have:
>>
>> olcTLSCACertificatePath: /etc/pki/nssdb
>> olcTLSCertificateFile: endoframe
>>
>> I have used certutil to create a self-signed certificate:
>>
>> # certutil -d /etc/pki/nssdb -L
>>
>> Certificate Nickname Trust
>> Attributes
>>
>> SSL,S/MIME,JAR/XPI
>>
>> endoframe
>> Cu,Cu,Cu
>>
>> But this doesn't appear to be working:
>>
>> $ ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
>> ldap_url_parse_ext(ldaps://rail)
>> ldap_create
>> ldap_url_parse_ext(ldaps://rail:636/??base)
>> ldap_sasl_bind
>> ldap_send_initial_request
>> ldap_new_connection 1 1 0
>> ldap_int_open_connection
>> ldap_connect_to_host: TCP rail:636
>> ldap_new_socket: 3
>> ldap_prepare_socket: 3
>> ldap_connect_to_host: Trying ::1 636
>> ldap_pvt_connect: fd: 3 tm: -1 async: 0
>> ldap_close_socket: 3
>> ldap_new_socket: 3
>> ldap_prepare_socket: 3
>> ldap_connect_to_host: Trying 127.0.0.1:636
>> ldap_pvt_connect: fd: 3 tm: -1 async: 0
>> ldap_close_socket: 3
>> ldap_err2string
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>
>> slapd is running:
>>
>> # systemctl status slapd.service
>> slapd.service - LSB: starts and stopd OpenLDAP server daemon
>> Loaded: loaded (/etc/rc.d/init.d/slapd)
>> Active: active (running) since Wed, 05 Oct 2011 02:24:11
>> -0400; 3 weeks and 0 days ago
>> Main PID: 1429 (slapd)
>> CGroup: name=systemd:/system/slapd.service
>> └ 1429 /usr/sbin/slapd -h ldap:/// -u ldap
>>
>> Any ideas of what I might be doing wrong, or where I should be looking
>> to debug this?
>>
>
> slapd was not started with the proper options to listen on ldaps:/// (port
> 636).
>
> Your -h command line option should include it, e.g. '-h ldap:///
> ldaps:///'. See slapd(8) for more details.
>
>
There is a control file on Fedora 15 for ldaps or tls
cat /etc/sysconfig/ldap
# Options of slapd (see man slapd)
#SLAPD_OPTIONS=
# At least one of SLAPD_LDAP, SLAPD_LDAPI and SLAPD_LDAPS must be set to
'yes'!
#
# Run slapd with -h "... ldap:/// ..."
# yes/no, default: yes
#SLAPD_LDAP=yes
# Run slapd with -h "... ldapi:/// ..."
# yes/no, default: no
#SLAPD_LDAPI=no
# Run slapd with -h "... ldaps:/// ..."
# yes/no, default: no
#SLAPD_LDAPS=no
SLAPD_LDAPS=yes
# Run slapd with -h "... $SLAPD_URLS ..."
# This option could be used instead of previous three ones, but:
# - it doesn't overwrite settings of $SLAPD_LDAP, $SLAPD_LDAPS and
$SLAPD_LDAPI options
# - it isn't overwritten by settings of $SLAPD_LDAP, $SLAPD_LDAPS and
$SLAPD_LDAPI options
# example: SLAPD_URLS="ldapi:///var/lib/ldap_root/ldapi ldapi:/// ldaps:///"
# default: empty
#SLAPD_URLS=""
# Maximum allowed time to wait for slapd shutdown on 'service ldap stop' (in
seconds)
#SLAPD_SHUTDOWN_TIMEOUT=3
# Parameters to ulimit, use to change system limits for slapd
#SLAPD_ULIMIT_SETTINGS=""
7:37 a.m.
On Wed, 2011-10-26 at 22:28 -0500, Dan White wrote:
On 26/10/11 22:53 -0400, Braden McDaniel wrote:
>I am trying to get OpenLDAP (2.4.24) working with NSS on Fedora 15. In
>cn=config.ldif I have:
>
> olcTLSCACertificatePath: /etc/pki/nssdb
> olcTLSCertificateFile: endoframe
[snip]
>Any ideas of what I might be doing wrong, or where I should be
looking
>to debug this?
slapd was not started with the proper options to listen on ldaps:/// (port
636).
Thank you. That got me this far:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: file endoframe.pem does not end in [.0] - does not appear to be a CA
certificate directory file with a properly hashed file name - skipping.
TLS: error: connect - force handshake failure: errno 0 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
I don't understand why it's looking for a file here. My impression from
reading <http://www.openldap.org/faq/data/cache/1514.html> is that the
cert would be pulled from the database.
--
Braden McDaniel <braden(a)endoframe.com>
7:44 a.m.
On 10/27/2011 08:37 AM, Braden McDaniel wrote:
On Wed, 2011-10-26 at 22:28 -0500, Dan White wrote:
> On 26/10/11 22:53 -0400, Braden McDaniel wrote:
>> I am trying to get OpenLDAP (2.4.24) working with NSS on Fedora 15. In
>> cn=config.ldif I have:
>>
>> olcTLSCACertificatePath: /etc/pki/nssdb
>> olcTLSCertificateFile: endoframe
[snip]
>> Any ideas of what I might be doing wrong, or where I should be looking
>> to debug this?
> slapd was not started with the proper options to listen on ldaps:/// (port
> 636).
Thank you. That got me this far:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: file endoframe.pem does not end in [.0] - does not appear to be a CA
certificate directory file with a properly hashed file name - skipping.
TLS: error: connect - force handshake failure: errno 0 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
I don't understand why it's looking for a file here. My impression from
reading<http://www.openldap.org/faq/data/cache/1514.html> is that the
cert would be pulled from the database.
What is your /etc/openldap/ldap.conf?
11:05 a.m.
On Thu, 2011-10-27 at 08:44 -0600, Rich Megginson wrote:
[snip]
What is your /etc/openldap/ldap.conf?
That question led me to a bogus setting for TLS_CACERTDIR. First, I
tried simply commenting the line out, figuring the value of
olcTLSCACertificatePath in cn=config.ldif would be used. That produced
this:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
So, instead, I set the value of TLS_CACERTDIR to match that of
olcTLSCACertificatePath. ldap.conf now looks like this:
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
URI ldap://rail.endoframe.net/
BASE dc=endoframe,dc=net
TLS_CACERTDIR /etc/pki/nssdb
That still doesn't do the trick; but it did change the error message:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: using moznss security dir /etc/pki/nssdb prefix .
TLS: error: tlsm_PR_Recv returned 0 - error 17:File exists
TLS: error: connect - force handshake failure: errno 17 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
--
Braden McDaniel <braden(a)endoframe.com>
11:27 a.m.
On 11-10-27 2:05 PM, Braden McDaniel wrote:
On Thu, 2011-10-27 at 08:44 -0600, Rich Megginson wrote:
[snip]
> What is your /etc/openldap/ldap.conf?
That question led me to a bogus setting for TLS_CACERTDIR. First, I
tried simply commenting the line out, figuring the value of
olcTLSCACertificatePath in cn=config.ldif would be used. That produced
this:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
So, instead, I set the value of TLS_CACERTDIR to match that of
olcTLSCACertificatePath. ldap.conf now looks like this:
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
URI ldap://rail.endoframe.net/
BASE dc=endoframe,dc=net
TLS_CACERTDIR /etc/pki/nssdb
That still doesn't do the trick; but it did change the error message:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: using moznss security dir /etc/pki/nssdb prefix .
TLS: error: tlsm_PR_Recv returned 0 - error 17:File exists
TLS: error: connect - force handshake failure: errno 17 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
why don't you simply try
TLS_CACERT /etc/pki/nssdb/<filename>
instead of
TLS_CACERTDIR /etc/pki/nssdb
12:41 p.m.
On Oct 27, 2011, at 2:27 PM, Daniel Qian wrote:
why don't you simply try
TLS_CACERT /etc/pki/nssdb/<filename>
instead of
TLS_CACERTDIR /etc/pki/nssdb
Because the cert isn't in a text file; it's in the NSS database.
--
Braden McDaniel
e-mail/Jabber IM: braden(a)endoframe.com
http://endoframe.com
1:22 p.m.
On 11-10-27 3:41 PM, Braden Northington McDaniel wrote:
On Oct 27, 2011, at 2:27 PM, Daniel Qian wrote:
> why don't you simply try
>
> TLS_CACERT /etc/pki/nssdb/<filename>
> instead of
>
>
> TLS_CACERTDIR /etc/pki/nssdb
Because the cert isn't in a text file; it's in the NSS database.
I saw similar problems to what you are having but it was for openssl and
can be fixed by running an openssl command plus some options. In your
case it seems the NSS database isn't in the format ldap client expects.
1:52 p.m.
Daniel Qian wrote:
On 11-10-27 3:41 PM, Braden Northington McDaniel wrote:
> On Oct 27, 2011, at 2:27 PM, Daniel Qian wrote:
>
>> why don't you simply try
>>
>> TLS_CACERT /etc/pki/nssdb/<filename>
>> instead of
>>
>>
>> TLS_CACERTDIR /etc/pki/nssdb
> Because the cert isn't in a text file; it's in the NSS database.
>
I saw similar problems to what you are having but it was for openssl and can
be fixed by running an openssl command plus some options. In your case it
seems the NSS database isn't in the format ldap client expects.
Note that by default, NSS expects to see a certificate database. You need an
additional module to enable it to use PEM files.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12:55 p.m.
On 10/27/2011 12:05 PM, Braden McDaniel wrote:
On Thu, 2011-10-27 at 08:44 -0600, Rich Megginson wrote:
[snip]
> What is your /etc/openldap/ldap.conf?
That question led me to a bogus setting for TLS_CACERTDIR. First, I
tried simply commenting the line out, figuring the value of
olcTLSCACertificatePath in cn=config.ldif would be used.
No, the client cannot use cn=config.ldif - that is for the server only.
The server cannot use ldap.conf - that is for the client only.
That produced
this:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
So, instead, I set the value of TLS_CACERTDIR to match that of
olcTLSCACertificatePath. ldap.conf now looks like this:
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
URI ldap://rail.endoframe.net/
BASE dc=endoframe,dc=net
TLS_CACERTDIR /etc/pki/nssdb
That still doesn't do the trick; but it did change the error message:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: using moznss security dir /etc/pki/nssdb prefix .
TLS: error: tlsm_PR_Recv returned 0 - error 17:File exists
TLS: error: connect - force handshake failure: errno 17 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Never seen that
- I have no idea why you would get an EEXIST at this
point in the code. I suggest turn on debugging on the server and see
what it thinks is happening.
8:25 p.m.
On Thu, 2011-10-27 at 13:55 -0600, Rich Megginson wrote:
On 10/27/2011 12:05 PM, Braden McDaniel wrote:
> On Thu, 2011-10-27 at 08:44 -0600, Rich Megginson wrote:
>
> [snip]
>
>> What is your /etc/openldap/ldap.conf?
> That question led me to a bogus setting for TLS_CACERTDIR. First, I
> tried simply commenting the line out, figuring the value of
> olcTLSCACertificatePath in cn=config.ldif would be used.
No, the client cannot use cn=config.ldif - that is for the server only.
The server cannot use ldap.conf - that is for the client only.
Okay... With this in mind, I changed ldap.conf to use TLS_CACERT to
point to a .pem file as generated by:
# certutil -d /etc/pki/nssdb -L -n "endoframe" -a >
endoframe.pem
That gets me here:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: loaded CA certificate
file /etc/openldap/cacerts/endoframe.pem.
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errno 21 - moznss
error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Never seen that - I have no idea why you would get an EEXIST at this
point in the code. I suggest turn on debugging on the server and see
what it thinks is happening.
There were apparently some selinux issues that accounted for the
previous errors. Once those were resolved, the above search yields this
from the server (run with -d1):
slap_listener_activate(10):
>> slap_listener(ldaps:///)
connection_get(14):
got connid=1000
connection_read(14): checking for input on id=1000
TLS: using moznss security dir /etc/pki/nssdb prefix .
TLS: certificate [CN=Endoframe] is not valid - error -8102:Unknown code ___f 90.
TLS: error: unable to find and verify server's cert and key for certificate
endoframe
TLS: error: could not initialize moznss security context - error -8102:Unknown
code ___f 90
TLS: can't create ssl handle.
connection_read(14): TLS accept failure error=-1 id=1000, closing
connection_close: conn=1000 sd=14
So I screwed up the certificate. I'm just not sure how.
--
Braden McDaniel <braden(a)endoframe.com>
7:09 a.m.
On 11/12/2011 09:25 PM, Braden McDaniel wrote:
On Thu, 2011-10-27 at 13:55 -0600, Rich Megginson wrote:
> On 10/27/2011 12:05 PM, Braden McDaniel wrote:
>> On Thu, 2011-10-27 at 08:44 -0600, Rich Megginson wrote:
>>
>> [snip]
>>
>>> What is your /etc/openldap/ldap.conf?
>> That question led me to a bogus setting for TLS_CACERTDIR. First, I
>> tried simply commenting the line out, figuring the value of
>> olcTLSCACertificatePath in cn=config.ldif would be used.
> No, the client cannot use cn=config.ldif - that is for the server only.
> The server cannot use ldap.conf - that is for the client only.
Okay... With this in mind, I changed ldap.conf to use TLS_CACERT to
point to a .pem file as generated by:
# certutil -d /etc/pki/nssdb -L -n "endoframe" -a>
endoframe.pem
That gets me here:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: loaded CA certificate
file /etc/openldap/cacerts/endoframe.pem.
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errno 21 - moznss
error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> Never seen that - I have no idea why you would get an EEXIST at this
> point in the code. I suggest turn on debugging on the server and see
> what it thinks is happening.
There were apparently some selinux issues that accounted for the
previous errors. Once those were resolved, the above search yields this
from the server (run with -d1):
slap_listener_activate(10):
>>> slap_listener(ldaps:///)
connection_get(14): got connid=1000
connection_read(14): checking for input on id=1000
TLS: using moznss security dir /etc/pki/nssdb prefix .
TLS: certificate [CN=Endoframe] is not valid - error -8102:Unknown code ___f
90.
TLS: error: unable to find and verify server's cert and key for certificate
endoframe
TLS: error: could not initialize moznss security context - error -8102:Unknown
code ___f 90
TLS: can't create ssl handle.
connection_read(14): TLS accept failure error=-1 id=1000, closing
connection_close: conn=1000 sd=14
So I screwed up the certificate. I'm just not sure how.
-8102:Unknown code
___f 90 is SEC_ERROR_INADEQUATE_KEY_USAGE - can you
post the contents of your certificate?
certutil -d /etc/pki/nssdb -L -n CN=Endoframe
then delete/obscure any sensitive information
then post the cert
5:37 a.m.
FYI,
You have my close attention:
I am running ldap / slapd at 2.4.26 / the Suse 12.1 milepost 5
I have a tls problem / worked on it with nss,
Then someone mentioned that it may be solvable with nslcd, so I changed to
nslcd, but the problem doesn't appear to have changed.
I initially thought it was a bad cert, but used:
openssl verify -CAfile cacert.pem servercert.pem
[Christopher Wood suggestion]
And the cert verified.
Waiting for a resolution to see if it sheds light on my problem.
tob
On 11/14/11 10:09 AM, "Rich Megginson" <rich.megginson(a)gmail.com> wrote:
On 11/12/2011 09:25 PM, Braden McDaniel wrote:
> On Thu, 2011-10-27 at 13:55 -0600, Rich Megginson wrote:
>> On 10/27/2011 12:05 PM, Braden McDaniel wrote:
>>> On Thu, 2011-10-27 at 08:44 -0600, Rich Megginson wrote:
>>>
>>> [snip]
>>>
>>>> What is your /etc/openldap/ldap.conf?
>>> That question led me to a bogus setting for TLS_CACERTDIR. First, I
>>> tried simply commenting the line out, figuring the value of
>>> olcTLSCACertificatePath in cn=config.ldif would be used.
>> No, the client cannot use cn=config.ldif - that is for the server only.
>> The server cannot use ldap.conf - that is for the client only.
> Okay... With this in mind, I changed ldap.conf to use TLS_CACERT to
> point to a .pem file as generated by:
>
> # certutil -d /etc/pki/nssdb -L -n "endoframe" -a>
> endoframe.pem
>
> That gets me here:
>
> # ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
> ldap_url_parse_ext(ldaps://rail)
> ldap_create
> ldap_url_parse_ext(ldaps://rail:636/??base)
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP rail:636
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying ::1 636
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> TLS: loaded CA certificate
> file /etc/openldap/cacerts/endoframe.pem.
> TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
> TLS: error: connect - force handshake failure: errno 21 - moznss
> error -5938
> TLS: can't connect: TLS error -5938:Encountered end of file.
> ldap_err2string
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>
>> Never seen that - I have no idea why you would get an EEXIST at this
>> point in the code. I suggest turn on debugging on the server and see
>> what it thinks is happening.
> There were apparently some selinux issues that accounted for the
> previous errors. Once those were resolved, the above search yields this
> from the server (run with -d1):
>
> slap_listener_activate(10):
>>>> slap_listener(ldaps:///)
> connection_get(14): got connid=1000
> connection_read(14): checking for input on id=1000
> TLS: using moznss security dir /etc/pki/nssdb prefix .
> TLS: certificate [CN=Endoframe] is not valid - error -8102:Unknown
> code ___f 90.
> TLS: error: unable to find and verify server's cert and key for
> certificate endoframe
> TLS: error: could not initialize moznss security context - error
> -8102:Unknown code ___f 90
> TLS: can't create ssl handle.
> connection_read(14): TLS accept failure error=-1 id=1000, closing
> connection_close: conn=1000 sd=14
>
> So I screwed up the certificate. I'm just not sure how.
-8102:Unknown code ___f 90 is SEC_ERROR_INADEQUATE_KEY_USAGE - can you
post the contents of your certificate?
certutil -d /etc/pki/nssdb -L -n CN=Endoframe
then delete/obscure any sensitive information
then post the cert
2:56 a.m.
[My, it's been a while. I got pulled away from this and it's been a
busy few months. Now I'm beating my head against it some more.]
I backed up and started over with this. Here is the state of things:
# certutil -d /etc/pki/nssdb -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
LDAP-Server-Cert u,u,u
CA certificate CTu,u,u
# certutil -d /etc/pki/nssdb -L -n 'CA certificate'
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1000 (0x3e8)
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "CN=Endoframe CA cert,DC=endoframe,DC=net"
Validity:
Not Before: Tue Jan 17 07:48:20 2012
Not After : Mon Jan 17 07:48:20 2022
Subject: "CN=Endoframe CA cert,DC=endoframe,DC=net"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
[snip]
Signed Extensions:
Name: Certificate Basic Constraints
Critical: True
Data: Is a CA with no maximum path length.
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Signature:
[snip]
Fingerprint (MD5):
[snip]
Fingerprint (SHA1):
[snip]
Certificate Trust Flags:
SSL Flags:
Valid CA
Trusted CA
User
Trusted Client CA
Email Flags:
User
Object Signing Flags:
User
# certutil -d /etc/pki/nssdb -L -n 'LDAP-Server-Cert'
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1001 (0x3e9)
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "CN=Endoframe CA cert,DC=endoframe,DC=net"
Validity:
Not Before: Thu Jan 19 06:13:01 2012
Not After : Wed Jan 19 06:13:01 2022
Subject: "CN=ldap.endoframe.net"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
[snip]
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Signature:
[snip]
Fingerprint (MD5):
[snip]
Fingerprint (SHA1):
[snip]
Certificate Trust Flags:
SSL Flags:
User
Email Flags:
User
Object Signing Flags:
User
Given the above, I generate the cert for the client:
# certutil -d /etc/pki/nssdb -L -n LDAP-Server-Cert -a >
/etc/openldap/cacerts/ldap-server-cert.pem
In cn=config.ldif, I have:
olcTLSCACertificatePath: /etc/pki/nssdb
olcTLSCertificateFile: LDAP-Server-Cert
In ldap.conf, I have:
TLS_CACERT /etc/openldap/cacerts/ldap-server-cert.pem
Finally, when I run ldapsearch, I get this error:
# ldapsearch -H ldaps://ldap.endoframe.net -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://ldap.endoframe.net)
ldap_create
ldap_url_parse_ext(ldaps://ldap.endoframe.net:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.endoframe.net:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.0.0.21:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: loaded CA certificate file /etc/openldap/cacerts/ldap-server-cert.pem.
TLS: certificate [CN=Endoframe CA cert,DC=endoframe,DC=net] is not valid - error
-8172:Peer's certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 21 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been
marked as not trusted by the user..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Is there something I need to do to mark the issuer as trusted on the
client? (The client and server are actually the same machine in this
case, FWIW.)
Braden
8:43 a.m.
Yes: Specify your cacert file in openldap's ldap.conf file (NOT PADL's in /etc/):
typically /etc/openldap/ldap.conf or perhaps /usr/local/openldap/etc/openldap/ldap.conf.
If the cert is signed by a real CA then your system's cacert bundle needs updating.
If not, then I recommend you setup your own internal CA - it doesn't need to always be
running nor even have network connectivity.
And use openssl vs mozilla's ssl - my understanding is that it doesn't quite work
right; especially when building openldap.
- chris
----- Original Message -----
From: openldap-technical-bounces(a)OpenLDAP.org
<openldap-technical-bounces(a)OpenLDAP.org>
To: richm(a)stanfordalumni.org <richm(a)stanfordalumni.org>
Cc: openldap-technical(a)openldap.org <openldap-technical(a)openldap.org>
Sent: Sun Feb 05 03:56:18 2012
Subject: Re: Using NSS
[My, it's been a while. I got pulled away from this and it's been a
busy few months. Now I'm beating my head against it some more.]
I backed up and started over with this. Here is the state of things:
# certutil -d /etc/pki/nssdb -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
LDAP-Server-Cert u,u,u
CA certificate CTu,u,u
# certutil -d /etc/pki/nssdb -L -n 'CA certificate'
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1000 (0x3e8)
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "CN=Endoframe CA cert,DC=endoframe,DC=net"
Validity:
Not Before: Tue Jan 17 07:48:20 2012
Not After : Mon Jan 17 07:48:20 2022
Subject: "CN=Endoframe CA cert,DC=endoframe,DC=net"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
[snip]
Signed Extensions:
Name: Certificate Basic Constraints
Critical: True
Data: Is a CA with no maximum path length.
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Signature:
[snip]
Fingerprint (MD5):
[snip]
Fingerprint (SHA1):
[snip]
Certificate Trust Flags:
SSL Flags:
Valid CA
Trusted CA
User
Trusted Client CA
Email Flags:
User
Object Signing Flags:
User
# certutil -d /etc/pki/nssdb -L -n 'LDAP-Server-Cert'
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1001 (0x3e9)
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "CN=Endoframe CA cert,DC=endoframe,DC=net"
Validity:
Not Before: Thu Jan 19 06:13:01 2012
Not After : Wed Jan 19 06:13:01 2022
Subject: "CN=ldap.endoframe.net"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
[snip]
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Signature:
[snip]
Fingerprint (MD5):
[snip]
Fingerprint (SHA1):
[snip]
Certificate Trust Flags:
SSL Flags:
User
Email Flags:
User
Object Signing Flags:
User
Given the above, I generate the cert for the client:
# certutil -d /etc/pki/nssdb -L -n LDAP-Server-Cert -a >
/etc/openldap/cacerts/ldap-server-cert.pem
In cn=config.ldif, I have:
olcTLSCACertificatePath: /etc/pki/nssdb
olcTLSCertificateFile: LDAP-Server-Cert
In ldap.conf, I have:
TLS_CACERT /etc/openldap/cacerts/ldap-server-cert.pem
Finally, when I run ldapsearch, I get this error:
# ldapsearch -H ldaps://ldap.endoframe.net -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://ldap.endoframe.net)
ldap_create
ldap_url_parse_ext(ldaps://ldap.endoframe.net:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.endoframe.net:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.0.0.21:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: loaded CA certificate file /etc/openldap/cacerts/ldap-server-cert.pem.
TLS: certificate [CN=Endoframe CA cert,DC=endoframe,DC=net] is not valid - error
-8172:Peer's certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 21 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been
marked as not trusted by the user..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Is there something I need to do to mark the issuer as trusted on the
client? (The client and server are actually the same machine in this
case, FWIW.)
Braden
This message is private and confidential. If you have received it in error, please notify
the sender and remove it from your system.
10:02 p.m.
On Sun, 2012-02-05 at 09:43 -0700, Chris Jacobs wrote:
Yes: Specify your cacert file in openldap's ldap.conf file (NOT
PADL's in /etc/): typically /etc/openldap/ldap.conf or perhaps
/usr/local/openldap/etc/openldap/ldap.conf.
That's it. Thank you!
If the cert is signed by a real CA then your system's cacert
bundle needs updating.
It's self-signed. And (I *think*) things are working.
And use openssl vs mozilla's ssl - my understanding is that it
doesn't quite work right; especially when building openldap.
I'm using Fedora's binaries; and they're built against NSS these days.
Braden
11:15 a.m.
On 11-10-27 10:37 AM, Braden McDaniel wrote:
On Wed, 2011-10-26 at 22:28 -0500, Dan White wrote:
> On 26/10/11 22:53 -0400, Braden McDaniel wrote:
>> I am trying to get OpenLDAP (2.4.24) working with NSS on Fedora 15. In
>> cn=config.ldif I have:
>>
>> olcTLSCACertificatePath: /etc/pki/nssdb
>> olcTLSCertificateFile: endoframe
[snip]
>> Any ideas of what I might be doing wrong, or where I should be looking
>> to debug this?
> slapd was not started with the proper options to listen on ldaps:/// (port
> 636).
Thank you. That got me this far:
# ldapsearch -H ldaps://rail -b dc=endoframe,dc=net -x -d1
ldap_url_parse_ext(ldaps://rail)
ldap_create
ldap_url_parse_ext(ldaps://rail:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP rail:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: file endoframe.pem does not end in [.0] - does not appear to be a CA
certificate directory file with a properly hashed file name - skipping.
TLS: error: connect - force handshake failure: errno 0 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
I don't understand why it's looking for a file here. My impression from
reading<http://www.openldap.org/faq/data/cache/1514.html> is that the
cert would be pulled from the database.
I think that error message is from your client side missing CA cert
settings. try run 'authconfig-tui' command to see if that fixes it.
4320
days inactive
4422
days old
openldap-technical@openldap.org
19 comments
8 participants
participants (8)
-
Braden McDaniel -
Braden Northington McDaniel
-
Chris Jacobs -
Dan White -
Daniel Qian -
Howard Chu -
John Tobin -
Rich Megginson