< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] TLS certificate question


Additional info on this thread:

resiprocate is coring if the client 'store' does not contain a cert for
the server as mentioned below. The core seems to be from this code from
TlsConnection::computePeerName.

   if ( !mSecurity->hasDomainCert( mPeerName ) )
   {
      unsigned char* buf = NULL;
      int len = i2d_X509( cert, &buf );
      Data derCert( buf, len );
      mSecurity->addDomainCertDER(mPeerName,derCert);
      free(buf); buf=NULL; // TODO - this may leak
   }

The 'if' check fails, so it calls i2d_X509 to convert the presented cert
to a char* buffer. It is coring in there. The stack trace is not very
helpful.  All I see in there is:
(gdb) thread apply all bt

Thread 1 (process 26118):
#0  0x402053f7 in c2i_ASN1_INTEGER () from ../lib/libjcore.so.2.3
#1  0xbd1c4678 in ?? ()
Cannot access memory at address 0x10
(gdb)


On Mon, 2005-05-23 at 12:31 -0600, Sandeep Sharma wrote:
> Hi,
> 
> I have a question on resiprocate TLS certificate stuff. When resiprocate
> acts as a TLS client and connects to another domain, which presents a
> TLS certificate with a subject name of "other.domain.com", resiprocate
> seems to be looking for a cert file called
> domain_cert_other.domain.com.pem  in its store. If it does not find the
> cert, it seems to try to create a new file with that name, and that
> fails.
> 
> If I create a file with that name and the cert in it, before attempting
> to connect, then resiprocate finds it in the store and connection goes
> through smoothly.
> 
> My question is: is this expected behavior? I was under the impression
> that the TLS client only needs to know about the root cert or certs in
> the chain of the server cert.
> 
> I am using a month old version of resiprocate.
> 
> Any information is greatly appreciated.
> 
> Thanks
-- 
Sandeep Sharma <ssharma@xxxxxxxxxx>