Hi all,

I have two problems and could use some help.  

First problem:  I am doing client authentication.  It all works fine, until
a client sends a bad certificate that is rejected by my server.  After that
point, my server can't accept any more connections.  Every connection
attempt - regardless of the validity of the client's certificate -  fails in
the Server's call to "SSL_CTX_load_verify_locations (_pctxSSLContext,
_pszCAFile, _pszCAPath)"  (I'm using a new context for each new connection).
Why would this be?

The other problem is suggested by the first.  I can't find out what's wrong
because the error system appears to be broken.  The following code:

iRes = SSL_CTX_load_verify_locations (_pctxSSLContext, _pszCAFile,
_pszCAPath);
            if (iRes <= 0)
            {
                int iSSLErrno = SSL_get_error (_psslConnection, iRes);
                printf ("iRes = %d, iSSLErrno = %d\nErrStr: %s\nLibErr:
%s\nFncErr: %s\nRsnErr: %s\n", 
                                iRes,  SSLErrno, 
                                ERR_error_string(iSSLErrno, NULL), 
                                ERR_lib_error_string(iSSLErrno), 
                                ERR_func_error_string(iSSLErrno), 
                                ERR_reason_error_string(iSSLErrno));
        }
produces the following output:

iRes = 0, iSSLErrno = 1
                ErrStr: error:00000001::lib(0) :func(0) :reason(1)
LibErr: (null)
FncErr: (null)
RsnErr: (null)

I am calling:
                SSL_load_error_strings();
                ERR_load_ERR_strings();
At startup.

What on earth is going on??  Why might "SSL_CTX_load_verify_locations" fail
after a client certificate is rejected, and why doesn't the error system
report errors?

Thanks for the help!

Bill Rebey



-----Original Message-----
From:   John Hartnup [mailto:[EMAIL PROTECTED]]
Sent:   Tuesday, June 20, 2000 9:57 AM
To:     [EMAIL PROTECTED]
Subject:        Re: OT: determining des vs. md5 vs ?

On Tue, Jun 20, 2000 at 09:47:54AM -0400, Rich Salz wrote:
> > sql table.  I need to initialize the user/passwd data base with the
> > existing data from my current /etc/passwd file (linux).
> 
> No can do.  The password file format is one-way.  You cannot recover the
> password from the password file.

I think the original poster understood this: he would be storing the
DES crypt hashed password from /etc/passwd in his SQL database. New
passwords
would be hashed with MD5 crypt instead (he said) and the password verifying 
routine would be able to cope with either DES or MD5. No need to extract
plaintext passwords at any point there.

-- 
----------------------------------------------------------------------------
---
        Ooh, it's 'orrible being in love when you're eight and a half.
        I've got your picture on my wall and your name upon my scarf.
----------------------------------------------------------------------------
---

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to