ssl_callback_SSLVerify re-negotiation handshake crash

Love Hörnquist Åstrand <[email protected]>
Newsgroups gmane.comp.apache.mod-ssl.user
Message-ID <[email protected]>
Hello,

We are running 2.8.25-1.3.34 with openssl 0.9.7g. When using
client authentication we have crashes in ssl_callback_SSLVerify
relasted calls. Please see backtrace below.

The last entires in the log before the child httpd starts crashing is:

Awaiting re-negotiation handshake

Have anyone seen problems like this before and have a solution ?
If not, we'll go ahead and add more logging and do more debugging of
the problem.

Love


(gdb) bt
#0  CRYPTO_get_ex_data (ad=0xe8, idx=137019688) at ex_data.c:628
#1  0x4035c035 in SSL_get_ex_data (s=0x1, idx=296) at ssl_lib.c:2220
#2  0x4031cf08 in ssl_callback_SSLVerify (ok=1, ctx=0xbfffed20)
     at ssl_engine_kernel.c:1507
#3  0x404125ec in internal_verify (ctx=0x87f55e0) at x509_vfy.c:880
#4  0x40411e66 in X509_verify_cert (ctx=0xbfffed20) at x509_vfy.c:306
#5  0x00000002 in ?? ()
(gdb) print *ssl
Cannot access memory at address 0x0
(gdb) print *ctx
$19 = {
   ctx = 0x82aa680,
   current_method = 0,
   cert = 0x87f9740,
   untrusted = 0x881e2e8,
   purpose = 1,
   trust = 2,
   check_time = 0,
   flags = 0,
   other_ctx = 0x0,
   verify = 0x40412440 <internal_verify>,
   verify_cb = 0x4031cecd <ssl_callback_SSLVerify>,
   get_issuer = 0x40416750 <X509_STORE_CTX_get1_issuer>,
   check_issued = 0x40413200 <check_issued>,
   check_revocation = 0x40413270 <check_revocation>,
   get_crl = 0x40413410 <get_crl>,
   check_crl = 0x40413460 <check_crl>,
   cert_crl = 0x40413700 <cert_crl>,
   cleanup = 0,
   depth = 9,
   valid = 0,
   last_untrusted = 2,
   chain = 0x87f55e0,
   error_depth = 2,
   error = 0,
   current_cert = 0x82ac028,
   current_issuer = 0x82ac028,
   current_crl = 0x0,
   ex_data = {
     sk = 0x881bd10,
     dummy = 142729960
   }
PGP.sig (application/pgp-signature, 186 B) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.