> Date: Mon, 13 Dec 2010 10:33:15 +0100 (CET)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: certification error issue after running for a few cycles
> on Solaris
> Message-ID: <alpine.DEB.2.00.1012131029350.16941_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Mon, 13 Dec 2010, Fei Yan wrote:
>
> > I'm confronted with the following errors after running my application for
> a
> > while on Solaris 10 Sparc platform:
> > unable to use client certificate (no key found or wrong pass phrase?)
>
> What libcurl version? What OpenSSL version?
>

We use libcurl 7.21.2 and openssl 0.9.8o.

>
> I can see that error string getting used at three places in the code. I
> think
> a good idea would be for you to figure out exactly which of those errors
> you
> get.
>

That means rebuilding the library, right? Can we workaround that or is it
needed to add some trace code in the ssluse.c?

>
> My first gut reaction is that this looks like an OpenSSL problem, but of
> course I can't tell that for sure yet.
>

Not sure, but since that issue occurs on performance test, not sure if the
string passed to openssl API got changed or not.

>
> > The same easy handle is reused for successive file uploads with nearly
> > the same options, excluding the url, to upload to the same host. The same
> CA
> > file, client CERT file and client key file are used for all the transfer,
> > while all the credential files are of PEM format. We have several easy
> > handles shared as a pool to upload thousands of small files to the server
> > and each easy handle is guaranteed to be single threaded.
> >
> > We observed the key issues again and again, but after we cleaned up
> those
> > handles and re-created them, things went smoothly. Appreciate if anyone
> can
> > cast any light over this problem.
>
> Can you make the problem happen if you write up a test application that
> works
> in a similar way against a public URL or something?
>

The application is a bit complicated and requires high throughput behind a
LAN. I don't think any public site can afford such high load.

>
> Have you tried to take away some pieces from your puzzle to see if the
> problem
> remains? Like if you do the connections without client certs or if you
> don't
> verify the remote cert with a ca cert?
>

The server side mandate secure transfer and only support HTTPS right now. We
use CA cert and client private certs and key, all of them are of PEM format,
but without verify.

>
> --
>
> / daniel.haxx.se
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-12-15