On Wed, 31 Aug 2005, theo borm wrote:

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

Strictly speaking, it gets called for each new connect which could be made to
the same server if the connection gets dropped for whatever reason.

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

Right, it gets called in the setup-SSL-stuff function and that will be called
on repeateded connect attempts until it gets connected fine and then it won't
be called again for that connection.

I don't see how we can avoid that.

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

But why does it fail the two first times then?

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

That is unfortunately beyond what I know.

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

We don't have a policy for adding CA certs, so therefore it doesn't happen.

We cannot include what Mozilla includes due to license reasons[*]. Or at least
I don't want to distribute files using Mozilla's licensing in the curl release
archive(s) since they would stand out as very different than the rest of the
package. We do however provide a conversion service on the curl site that
converts the most recent Mozilla certs to a format suitable for curl.

So, the CA cert bundle in curl is slowly degrading over time.

Sure, we could start adding CA certs to the curl bundle but when doing so, we
should first decide on what requirements we have on new CA certs and on what
grounds we accept/reject additions. So far, I've not been overjoyed at the
thought of yet another task in a project I'm already up to my ears with work
in already. I would of course sallute and hail all efforts from interested
parties to help sort out this situation.

I've previously read complaints on how CA certs are accepted or not in the
Mozilla bundle, so I guess an alternative policy could be interesting. Of
course, in the end, it will be subject for complaints too...

[*] = If the certs actually are covered by the Mozilla licenses may be subject
       for discussions, but I rather just not do it to avoid the debate.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html