curl-library
Re: Using libcurl/SSL with in-core certificate - solved
Date: Thu, 01 Sep 2005 12:44:06 +0200
theo borm wrote:
> Daniel Stenberg wrote:
>
>>
>>> 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 first two times a dummy self-signed certificate identifying a
> different website was loaded - so failure was expected. The reason
> I tried twice was to see if loading the same (wrong) certificate in
> the "same" SSLCTX would lead to an error (for loading the same
> certificate twice) - which, surprisingly, it didn't in this case.
But, as one has told already, there is no "SAME" SSL_CTX. Each
connexion has a new one.
>
> If I take the standard certificate list (59 certificates IIRC), load
> that,
> and then add CACERTs' certificate, I end up with a list of 60
> certificates.
> If I load the standard certificate list and then try to add a certificate
> already present in this standard certificate list, this (of course)
> fails,
> and I end up with a list of 59 certificates.
> So adding the same certificate twice in the callback function EITHER
> takes another code path not complaining about duplicate certificates
> added through that route or (most likely) the same SSLCTX is
> reinitialized before the second call, forgetting about the previously
> manually added certificate.
See below: For each connection you have a new ssl_ctx.
>
> Anyway, this is not an error, but can be viewed (depending on your
> perspective) as a slight inconsistency in interface. I don't think that
> anything needs to change though. My perspective on libcurl (and
> openssl) is one of a documented black box with innards not to be
> touched unless absolutely nescessary.
It seems useful to me to add a sentence to the doc that for each call of
the ssl-ctx callback, a new fresh SSL_CTX context is used, thus it cannot
be used to store any information among session etc.
>
> With kind regards,
>
> Theo
>
>
>
>
>
>
-- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
- application/x-pkcs7-signature attachment: S/MIME Cryptographic Signature