cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Using libcurl/SSL with in-core certificate - solved

From: theo borm <theo_curl_at_borm.org>
Date: Wed, 31 Aug 2005 09:04:03 +0200

Peter Sylvester wrote:

>
> As far as I understand the logic, an SSL_ctx is created whenever a
> connection needs to be
> established, and the ssl ctx function is called exactly once for each
> ssl_ctx. Each ssl ctx
> is initialized with the values set via easy. Thus, the curl easy
> handle does basically most
> of what the ssl_ctx is doing, i.e., the house keeping of parameters.

You are basically correct. My mistake, sorry for the confusion.

My confusion stems from the fact that I (at first) tried to load a 'new'
certificate with the whole standard set already installed - In this case
the 'new' certificate was already present in the default set, and
an error is returned. I extrapolated this te mean something else, causing
this confusion

To summarize:

As far as I can tell (test case, not looking at sources), repeatedly
querying
pages from the same server leads to a single SSLCTX being created and
being reused on subsequent queries to the same server. If multiple servers
are being queried, then a separate SSLCTX is created for every server.

The call-back function seems to be called for every SSLCTX on every
query (to the same server) *until* a query succeeds - once a query succeeds,
then apparently a valid chain of trust has been established, and no further
changes to the SSLCTX are deemed nescessary.

In other words: If I have a global variable keeping track of the number
of times the call-back function was called, making the callback function
load the correct certificate only on the /third/ call, and loading a "dummy"
certificate (synthactically correct, but for the wrong domain) on other
calls,
and then query the same page five times, then the first two queries will
fail,
and the third, fourth and fifth query will succeed, and the call-back
function
will be called exactly three times - until it loads the correct certificate.
The only oddity in this scheme is that the second query does /not/ fail
because the same certificate is loaded twice, but rather because it's
the wrong
certificate, so there are apparently some differences between loading a
certificate (list) through standard curl_easy_setopt and loading the
certificate
through the call-back.

> Daniel Stenberg wrote:
>
>>
>> I'm sure I've missed something, I just can't see what!
>>
not much ...

on a side note: would CACert's root certificate be eligible for inclusion
in curls' root certificate list? or is the policy to include only what
Mozilla
includes?

cheers, Theo.
Received on 2005-08-31