Hi Max, thank you for your quick reply. I'm using the latest release I could find: ocspd-1.5.1-rc1, which is according to the changelog more than 3 years old. Is there any newer version I can try? The Openssl on the machine, the responder currently runs, is rather old: 0.9.7d, but the problem already occurred on another machine running a locally rebuilt ocspd with Openssl-0.9.8g. Trying to configure only one thread wasn't very successful - most of the time, I got no response at all. I'm very happy with the features of the current(?) ocspd release, if there only were no signature problem.
Thanks for your thoughts & Cheers, seBASStian > Hi Sebastian, > > I am not sure about which version you have, and, unfortunately, I had > no time to debug the new version we have laying there since the beginning > of this year (bad.. bad.. max!), but I think that the problem could be > related to threads management. > > I don't know if, in the version you have installed, the OpenSSL's thread > initialization is performed correctly... that might be a problem. A quick > fix (but I am not sure that might work, really) could be using only one > thread... > > The more sophisticated (but better) fix would be to urge me to release > the new code and test that :D > > As the new version of the OCSP uses LibPKI... I would suggest all the > OCSP server managers.. to take a brief look at it and its features (eg., > shell-oriented tools) that might be handy... > > Cheers, > Max > > > On 04/09/2010 02:49 PM, basscontrol wrote: >> Hi list, >> >> I successfully set up ocspd with data from 9 CAs as a single point of >> revokation data. I left most of the general options in ocspd.conf at >> their >> defaults. After starting the daemon, everything works as expected. A >> regular >> check (a Nagios check script which issues a request via openssl ocsp) >> shows whether the daemon is responding and the response contains the >> expected data. Now, after increasing usage of ocsp by local >> applications, >> after running for a while the daemon starts adding invalid signatures to >> its >> responses. A restart fixes the problem for another while, which can be >> days >> or just an hour. The Nagios check, running every few minutes, doesn't >> seem >> to trigger the problem, since until now it only occurs at daytimes. The >> logs >> (daemon is always started with -verbose) don't really tell a big story - >> there's >> no difference in the entries before, while and after the problem occurs. >> Trying to circumvent possible problems with temporary network or ca >> server >> outages, I switched from getting the crl info via HTTP to local files, >> regularly pulled by a separate script - but no success. The behaviour is >> the >> same as before. So, I think I need a little help from the list: What can >> cause the signatures suddenly become invalid and how to prevent this? >> Could this be an obscure bug in ocspd, maybe in conjunction with >> threading? >> >> seBASStian > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > Openca-Users mailing list > Openca-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openca-users > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Openca-Users mailing list Openca-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openca-users
