cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl_easy_perform() fails with "Problem with the SSL CA cert (path? access rights?)" after first time calling this routine

From: cnm marketing <cnn.marketing_at_gmail.com>
Date: Tue, 19 Mar 2013 08:52:32 -0400

>A hack could be to use libcurl without SSL use and setup stunnel as a last
resort to avoid using SSL on your many layers.
[cnm] What can exact libcurl or other routines/options be used, please give
a bit more details if it is possible.

On Sat, Mar 16, 2013 at 8:32 PM, cnm marketing <cnn.marketing_at_gmail.com>wrote:

>
> Here is a very brief overview of the layers:
> --------------------------------------------
> | Service Layer |
> | |
> --------------------------------------------
> | |
> ------------------- -----------------------
> | AAA Layer | ... | Others Layer |
> | | | |
> ------------------- ---------------------
> |
> -------------------
> | API Layers | ...
> | |
> -------------------
>
> Service layer - a daemon/service, it also contains many libraries (i.e.
> *.so on Linux), this layer use bsafe ssl, as well as openssl, this layer
> has its own bsafe and openssl libraries come with this layer.
>
> AAA Layer - plugin libraries (i.e. *.so), is loaded by Service Layer. This
> layer load libcurl via dlopen()/dlclose() and use libcurl routines to
> communicate to remote server to retrieve data. This layer do not do any
> openssl by itself (except libcurl invoke openssl). I believe libcurl will
> use the openssl in the local system ??!!
>
> API layers - many libraries, these libraries are linked into AAA Layer via
> compile link time. This layer uses openssl to communicate to the other
> remote server (not the same remote server in AAA Layer), it has its own
> openssl library come with this layer
>
> When the service layer starts, AAA Layer gets loaded into the service
> layer. Before libcurl in AAA Layer is called, the API Layers are getting
> loaded by AAA Layer, in the meantime, the openssl in API layers is getting
> call first. Then the libcurl in AAA Layer gets call and produce the error
> ""*error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too small"
> in libcurl output file via option CURLOPT_STDERR.
>
> However, on the same Linux system, I create a small program and uses the
> EXACT libcurl routines with dlopen()/dlclose(), this program retrieves the
> data from the same remote server just fine with CURLOPT_SSL_VERIFYPEER to 1
> or 0, i.e. with cert.pem or without cert.pem.
>
> Hopefully this is clear enough.
>
> On Sat, Mar 16, 2013 at 5:16 PM, cnm marketing <cnn.marketing_at_gmail.com>wrote:
>
>> We'll try your way and Yang's way to debug and see what the data looks
>> like in the openssl layer.
>>
>> I am a bit confused by Yang's comment "The problem is in the certificate
>> you are using which does not have a long enough Diffie-Hellman key.", as I
>> said the same error message shows up when I use the cert.pemm file or skip
>> the verifypeer check. How can the problem relate to the certificate if we
>> don't pass in cert.pem to libcurl.
>>
>> We also notice the comment in the link
>> http://comments.gmane.org/gmane.comp.encryption.openssl.user/43777 for
>> "FIPS-compliant constraints of the SSL stack there". The other group are
>> still trying to verify this.
>>
>> If I understand your comment correctly, are you saying libcurl uses the
>> openssl in the system (Linux) and OUR underneath software layers may use
>> other openssl from other area??!
>>
>>
>>
>> On Sat, Mar 16, 2013 at 7:33 AM, cnm marketing <cnn.marketing_at_gmail.com>wrote:
>>
>>> Thanks for the suggestion Oscar!
>>>
>>> We are still doing research on the link
>>> http://comments.gmane.org/gmane.comp.encryption.openssl.user/43777
>>> providered by Daniel, because it invokes other groups' work, it will
>>> take a while.
>>>
>>> In the meantime, we'd like to know in libcurl:
>>> 1. How do you invoke openssl in the case of CURLOPT_SSL_VERIFYPEER 0 and
>>> 1. Do you suppose to skip CA verification if CURLOPT_SSL_VERIFYPEER is 0,
>>> if it does, the how come you still have "*error:0506706E:Diffie-Hellman
>>> routines:GENERATE_KEY:key size too small*". Or this error has nothing
>>> to do with CURLOPT_SSL_VERIFYPEER ?! I am a bit confused by Yang's comment
>>> on checking the openssl key.
>>> 2. libcurl does not have any option to reset the key size, correct?
>>> 3. Since we have other layers that invokes openssl or/and bsafe, in our
>>> software we are not the one first get loaded into the memory, so the
>>> openssl from libcurl will use the openssl loaded by other layer. The reason
>>> that we think this may have something to do with the mixed openssl is - we
>>> create a small program that use the exact libcurl routine, this program
>>> works perfectly fine. It fails with the error "*error:0506706E:Diffie-Hellman
>>> routines:GENERATE_KEY:key size too small*" when we integrate this piece
>>> of code to our software layer. Any thought on this.
>>>
>>> On Fri, Mar 15, 2013 at 4:26 PM, cnm marketing <cnn.marketing_at_gmail.com
>>> > wrote:
>>>
>>>> >*error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too
>>>> small *
>>>> >libcurl does not fool around with certificate contents nor keys.
>>>> [cnm] libcurl uses openssl, that error message comes from openssl.
>>>> >The problem is in the certificate you are using which does not have a
>>>> long enough Diffie-Hellman key.
>>>> [cnm] I don't understand what you are refering to, please give a bit
>>>> more details. When we use libcurl, we don't set Diffie-Hellman key. We are
>>>> getting the same Diffie-Hellman error message for both CURLOPT_SSL_VERIFYPEER
>>>> to 1 and CURLOPT_SSL_VERIFYPEER to 0. Please refer to my previous
>>>> email thread!!
>>>>
>>>>
>>>> On Fri, Mar 15, 2013 at 2:59 PM, cnm marketing <cnn.marketing_at_gmail.com
>>>> > wrote:
>>>>
>>>>> >error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too
>>>>> small
>>>>> 1. When libcurl uses Diffie-Hellman, does libcurl hardcode the
>>>>> Diffie-Hellman key and the length?
>>>>> 2. Does libcurl have an option that allow libcurl user to re-set the
>>>>> Diffie-Hellman key length?
>>>>> We are still wondering (90% convinced) whether the error message has
>>>>> something to do with the openssl that is getting loaded from another layer.
>>>>> When the openssl is being loaded by another layer, libcurl is trying to use
>>>>> that openssl context and find the key size (set by libcurl) is too small
>>>>> compare to the key set by another layer.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 15, 2013 at 2:00 PM, cnm marketing <
>>>>> cnn.marketing_at_gmail.com> wrote:
>>>>>
>>>>>> >What SSL implementation is your libcurl using? How is the SSL
>>>>>> stack build and how did you build libcurl?
>>>>>> [cnm]
>>>>>> 1. I am not sure if I understand your first question, we use libcurl,
>>>>>> if libcurl uses ssl, then we use whatever is on the system, in our case, we
>>>>>> use openssl.
>>>>>> 2. We use dlopen()/dlsym()/dlclose() to load libcurl library. This is
>>>>>> the ONLY way that we can fit libcurl into our software layers. There are at
>>>>>> least 3 different layers in our layer that uses openssl, we are not the
>>>>>> first one to be loaded.
>>>>>>
>>>>>> On Fri, Mar 15, 2013 at 12:59 PM, cnm marketing <
>>>>>> cnn.marketing_at_gmail.com> wrote:
>>>>>>
>>>>>>> >libcurl is able to use 9 different SSL implementation as its SSL
>>>>>>> library for SSL connections. And yes, OpenSSL is one of them.
>>>>>>> [cnm] Does libcurl statically link ssl or dynamically load those
>>>>>>> ssl?
>>>>>>>
>>>>>>> >I've never seen the error message
>>>>>>> *> * error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size
>>>>>>> too small
>>>>>>> *
>>>>>>> [cnm] If you believe this error message is NOT from libcurl itself,
>>>>>>> then I believe this error message is from the openssl routines that the
>>>>>>> libcurl invokes. The question is why openssl throw this error, and in what
>>>>>>> situation (from libcurl code) this error will be throwed from libcurl?
>>>>>>> >What SSL implementation is your libcurl using? How is the SSL stack
>>>>>>> build and how did you build libcurl?
>>>>>>> [cnm]
>>>>>>> 1. I am not sure if I understand your first question, we use
>>>>>>> libcurl, if libcurl uses ssl, then we use whatever is on the system, in our
>>>>>>> case, we use openssl.
>>>>>>> 2. We use dlopen()/dlsym()/dlclose() to load libcurl library. This
>>>>>>> is the ONLY way that we can fit libcurl into our software layers. I need to
>>>>>>> check with other groups and see how many they use ssl in their layers. I'll
>>>>>>> get back to you on this.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 15, 2013 at 10:44 AM, cnm marketing <
>>>>>>> cnn.marketing_at_gmail.com> wrote:
>>>>>>>
>>>>>>>> How that can be? Does libcurl also use openssl?
>>>>>>>>
>>>>>>>> From my code, I only invoke libcurl routines. Again the following
>>>>>>>> output are the libcurl output by using CURLOPT_VERBOSE and CURLOPT_STDERR.
>>>>>>>> When setting CURLOPT_SSL_VERIFYHOST to 1, we got the debug1.txt
>>>>>>>> output, when setting CURLOPT_SSL_VERIFYHOST to 0, we get the
>>>>>>>> debug.txt output
>>>>>>>>
>>>>>>>>
>>>>>>>> [root_at_l2se0132 bin]# more /debug1.txt
>>>>>>>>
>>>>>>>> * About to connect() to l2se0060.lss.emc.com port 8443 (#0)
>>>>>>>>
>>>>>>>> * Trying 10.247.73.60...
>>>>>>>>
>>>>>>>> * Connected to l2se0060.lss.emc.com (10.247.73.60) port 8443 (#0)
>>>>>>>>
>>>>>>>> * successfully set certificate verify locations:
>>>>>>>>
>>>>>>>> * CAfile: /usr/yhuang/cert.pem
>>>>>>>>
>>>>>>>> CApath: none
>>>>>>>>
>>>>>>>> * error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too
>>>>>>>> small
>>>>>>>>
>>>>>>>> * Closing connection 0
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [root_at_l2se0132 bin]# more /debug.txt
>>>>>>>>
>>>>>>>> * About to connect() to l2se0060.lss.emc.com port 8443 (#0)
>>>>>>>>
>>>>>>>> * Trying 10.247.73.60...
>>>>>>>>
>>>>>>>> * Connected to l2se0060.lss.emc.com (10.247.73.60) port 8443 (#0)
>>>>>>>>
>>>>>>>> * error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too
>>>>>>>> small
>>>>>>>>
>>>>>>>> * Closing connection 0
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 15, 2013 at 3:45 AM, Daniel Stenberg <daniel_at_haxx.se>wrote:
>>>>>>>>
>>>>>>>>> On Thu, 14 Mar 2013, cnm marketing wrote:
>>>>>>>>>
>>>>>>>>> * error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too
>>>>>>>>>> small
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please stop top-posting and full-quoting.
>>>>>>>>>
>>>>>>>>> My 3.2 seconds of googling on this topic lead to this:
>>>>>>>>>
>>>>>>>>> http://comments.gmane.org/**gmane.comp.encryption.openssl.**
>>>>>>>>> user/43777<http://comments.gmane.org/gmane.comp.encryption.openssl.user/43777>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> / daniel.haxx.se
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-03-19