On 16-03-13 22:16, cnm marketing wrote: > We'll try your way and Yang's way to debug and see what the data looks > like in the openssl layer.
Yes, a bottom up debugging approach might give the insight you need here. But... I'm trying to understand your problem in your application... and I feel this part of the debugging is WAAAY beyond the scope of this mail list. Especially when you mention a normal curl execution just works. > 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. The Diffie-Hellman key exchange doesn't always mean the certificate file. It is an additional stage in the SSL handshake. If you use a specific DH-key, we wish to see what's in there. If you don't have one, perhaps there is somewhere else on the system one or it's generated dynamically. The problem is... we are walking in the blind here as you didn't disclose what your setup looks like and what input for SSL you have and use. If you don't know what this means, you are likely just using DH with dynamic key generation. I started looking up the code in OpenSSL and you can't really influence the size. Well, you can, at compile time for the most part of OpenSSL. > 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??! Yes, library loading can be a magical experience... :-) If you run the system supplied curl and you didn't change library loading stuff, you'll probably use the system OpenSSL libraries. But... I have no idea what you are doing in your application with already loaded OpenSSL. If the dynamic loader discovers you needed OpenSSL for libcurl and it's already satisfied by a previously loaded OpenSSL, it will skip loading the default OpenSSL from the system for libcurl and +1 the reference counter on the already loaded openssl library. Again... this piece of the puzzle is part of your application. I hope you can try to uncover this with the previously mentioned methods to chart the library loading at initial run-time and then you can start by charting the second dimension when you used dlopen/dlsym/dlclose. Oscar "loves a mystery without the burns"
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
