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

Re: Using NSS



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@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
>