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 a forked daemon is more robust than a multi-threaded one.. :(
Thanks for the advice - I will now put the locks back in place and see if the
server does
not crash anymore... :D
Later,
Max
Przemek Michalski wrote:
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 trick
here. I
have encountered a similar problem with pthreads and nShield 500 when
performing X.509
cert. signing. nCipher recommended to put dynamic locks in place but as in your
case -
it did not help.
Try to create your own static mutex and put it around your code right where you
perform
the signing/verification operation - that should help I think.
Without looking at the code, I am not sure what is the exact problem at your
end but in
my case (although I never went to properly investigate this matter) it looked
like it
was related to simultaneous communications between the application and the
nfast server
which sits in the middle between the application and the actual hardware device.
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.
P.M.
______________________________________________________________________ OpenSSL
Project
http://www.openssl.org User Support Mailing List
openssl-users@openssl.org Automated List Manager
[EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
