Re: Using NSS

[Rich Megginson <rich.megginson@gmail.com>]

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.