The server-side SNI support in OpenSSL seems to be targeted at HTTPS
virtual host configurations, in which each Virtual host is associated
with its own SSL_CTX object, initialized not only with a separate
key+cert+trust chain, but also with a separate cipherlist, list of
trusted CAs (really X509_S
On Friday 21 November 2008 14:41:08 Max Pala wrote:
> Hi Sander,
>
> I debugged the init process and it seems that you were right. The
> disable_mutex_callbacks is set to 1 at e_chil.c:578. Definitely it
> is due to initialization, at this point...
>
> ... looked into that, and... et voilas! Found
On Nov 21, 2008, at 11:12 AM, Massimiliano Pala wrote:
Hi Sander,
I debugged the init process and it seems that you were right. The
disable_mutex_callbacks is set to 1 at e_chil.c:578. Definitely it
is due to initialization, at this point...
... looked into that, and... et voilas! Found the p
Hi Sander,
I debugged the init process and it seems that you were right. The
disable_mutex_callbacks is set to 1 at e_chil.c:578. Definitely it
is due to initialization, at this point...
... looked into that, and... et voilas! Found the problem! The PRE
commands were wrong. Indeed the following:
Sander Temme wrote:
/opt/nfast/toolkits/openssl/openssl098e-patch.txt
I found a 'openssl098-patch.txt' is that ok ?
Should apply cleanly to newer versions of OpenSSL, with patch -p1. It
creates a static lock for CHIL to use so it doesn't need the dynamic
ones available.
It did.
I persona
On Fri, Nov 21, 2008, ThanhTrung Do wrote:
> > The reason for that is to detect I/O errors in the stream.
> >
> > The only reason I can think of for different behaviour is
> > if you have a memory
> > BIO:
> >
> > http://www.openssl.org/support/faq.html#PROG15
> >
> Thanks for your quick reply.
On Nov 20, 2008, at 5:13 PM, Max Pala wrote:
Hi Sander,
yep the order is correct - the thread callbacks (pthread) init
function
is before the Engine initialization (which happens before the spawning
of the threads).
The error you are describing sounds definitely familiar - although my
magi
On Friday 21 November 2008 11:07:19 Max Pala wrote:
> P.S.: As this code is basically the same for every application, what
> about integrating a nice OPENSSL_init_pthread() function that will
> initiate all the static locks and the dynamic functions ? That would
> save *a lot of time* to many peopl
On Nov 21, 2008, at 9:45 AM, Przemek Michalski wrote:
/opt/nfast/toolkits/openssl/openssl098e-patch.txt
Could you send/post the nCipher patch 0.9.8e - I am using one
supplied originally by nCipher for 0.9.8a
The source code bits in the patch are the same. The 'a' patch is
better, the
Sander,
>>/opt/nfast/toolkits/openssl/openssl098e-patch.txt
Could you send/post the nCipher patch 0.9.8e - I am using one supplied
originally by nCipher for 0.9.8a
Although the patch I have works well with all 0.9.8x versions I would be keen
to compare them just for my own curiosity.
thanks,
Have observed a similar problem despite the fact the nCipher patch is applied
and crypto locks (both static and dynamic) are set. Have never properly
investigated it so perhaps now is the time...
I checked this with two versions of OpenSSL 0.9.8h (without nCipher patch and
with the patch).
BTW
On Nov 21, 2008, at 8:07 AM, Max Pala wrote:
I definitely did - now I do initialize all the static locks in
OpenSSL *and* the
dynamic functions. But they are never called by the chil - the
assert fails and
the SIGABRT is sent to my daemon forcing it to exit.
The library needs both the sta
On Nov 21, 2008, at 8:50 AM, Max Pala wrote:
The problem is that they are not called by the nCipher driver - no
sign
at all in the logs... :( How come they are not called ???
Can you set a breakpoint in engines/e_chil.c:581 and inspect the value
of disable_mutex_callbacks? It should be
Hi Geoff,
I actually tried the same approach, I had a small test function that I call
at the start of each thread that initializes, locks, unlocks and destroys
the dyn locks.. and the functions are properly called.
unsigned long lock, lock2 = 0;
printf("About to test\n");
Hi Sander,
I definitely did - now I do initialize all the static locks in OpenSSL *and* the
dynamic functions. But they are never called by the chil - the assert fails and
the SIGABRT is sent to my daemon forcing it to exit.
For some reason it seems the dynamic locking functions do not function
Hello Przemek,
thanks for the advice - I already tried to use a mutex to protect the
OCSP_basic_sign(),
but I wanted to avoid it as this will just use only one thread at a time. It
seems that
nCipher is best used with a simple fork() daemon... if it wasn't for the shared
memories,
still today
On Nov 21, 2008, at 1:46 AM, Przemek Michalski wrote:
I also remember, that nCipher provides a patch for OpenSSL 0.9.8x
that makes some small changes to the original OpenSSL implementation
of CHIL.
You don't need that if you set the dynamic upcalls. Did you apply
that patch?
S.
--
[
Hello Przemek,
thanks for the advice - I already tried to use a mutex to protect the
OCSP_basic_sign(),
but I wanted to avoid it as this will just use only one thread at a time. It
seems that
nCipher is best used with a simple fork() daemon... if it wasn't for the shared
memories,
still today
On Friday 21 November 2008 03:01:33 Massimiliano Pala wrote:
> Hi David,
>
> that is really nice.. although.. after I gave it a try... it does not
> really work :(
>
> Actually, it seems that the dynamic functions are never called... :(
>
> Investigating...
The attached example seems to work. I pu
Dear All,
Thank you Dr. Stephen Henson for your Help.
I want to enable some selected cipher suite like
TLS_RSA_WITH_AES_256_CBC_SHA.
Can it is possible. I selected some specific Algorithm RSA, 3DES, AES,DES,
SHA and MD5.
So I want to enable cipher suite which support to above algorithms only. C
> The reason for that is to detect I/O errors in the stream.
>
> The only reason I can think of for different behaviour is
> if you have a memory
> BIO:
>
> http://www.openssl.org/support/faq.html#PROG15
>
Thanks for your quick reply.
Yes, I'm using memory BIO, I tried to call BIO_set_mem_eof_r
On Fri, Nov 21, 2008, ThanhTrung Do wrote:
> Hi forks,
>
> I've been using OpenSSL 0.9.8h, I use it for SMIME sign/verify. I've just
> upgraded to OpenSSL 0.9.8i and my code doesn't work anymore.
>
> The error is: [error:21075081:PKCS7 routines:PKCS7_verify:smime text error]
>
> After spending
Hi forks,
I've been using OpenSSL 0.9.8h, I use it for SMIME sign/verify. I've just
upgraded to OpenSSL 0.9.8i and my code doesn't work anymore.
The error is: [error:21075081:PKCS7 routines:PKCS7_verify:smime text error]
After spending sometime to investigate, I see the only diff is: the SMIME_
Baig, Attaullah wrote:
> Please help am I missing something
You are most likely not using the correct header files.
Some constants changed.
--
Arno Garrels
>
> Baig
__
OpenSSL Project http://www.
Dave Thompson wrote:
>> As a note: The certificates are *fine* I have used them successfully
>> with s_client and s_server tests. They verify perfectly well.
>>
> The one you've attached, yes; the one you are generating in code,
> maybe not, because s_client (and s_server) never does that.
Right,
Max,
>>Hi David,
>>
>>that is really nice.. although.. after I gave it a try... it does not really
>>work :(
>>
>>Actually, it seems that the dynamic functions are never called... :(
>>
>>Investigating...
>>
>>Later,
>>Max
It seems, that indeed the dynamic locking functions are not doing the tric
Hi David,
that is really nice.. although.. after I gave it a try... it does not really
work :(
Actually, it seems that the dynamic functions are never called... :(
Investigating...
Later,
Max
David Schwartz wrote:
Hi all,
it seems that I am missing the usage of the set of obscure functions
Please help am I missing something
Baig
28 matches
Mail list logo
