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>