Re: [reSIProcate-users] SSL not working with reSIProcate 1.4.1

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

The problem is that the post TLS handshake hostname validation check is failing.  When a TLS client connects to a server - it must check that the certificate presented by the server to the client identifies the server that it is trying to contact.  In SIP this means the hostname in the request URI of the SIP request you are sending must match either the certificate subject common name, or one of the SubjectAltNames (DNS or URI entries).  The following line in the logs indicate this error:

<<RESIP:TRANSPORT-ERROR>> Certificate name mismatch: trying to connect to <148.147.174.64> remote cert domain(s) are <Converged Communication Server 2.1>

There are two problems in your setup.  You are using an IP address to contact the server.  When using TLS you should always use hostnames or SRV records to connect to the TLS server.  Your certificate does not contain a valid hostname in the Subject CommonName field.

Hope this helps.

Scott

On Thu, Apr 9, 2009 at 6:51 AM, Srivastava, Rajeev Kumar (Rajeev) <srivastava@xxxxxxxxx> wrote:

Hello Scott,

 

Yes, my reSIProcate Application is TLS Client.

I am not sure what changes need to be done while generating Certificate to pass this host validation check.

Is this (the problem I am facing) because of wrong certificate or do I need to change my code to work with new version of reSIProcate?

 

As I am not very much knowledgeable in SSL stuff, I am attaching the reSIProcate logs along with the certificates I am using for further help on this.

 

Thanks,

~ Rajeev

 

From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: Tuesday, April 07, 2009 8:36 PM
To: Srivastava, Rajeev Kumar (Rajeev)
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SSL not working with reSIProcate 1.4.1

Is resiprocate the TLS client or server in these traces?  Are there any relevant errors in the resiprocate log files?  

Assuming your resiprocate application is the TLS client, it is tearing down the TLS connection after the handshake.  Usually this is because the post handshake host validation check failed.  The code surrounding hostname validation has changed since release 1.1.  The resip logs should contain some useful information if this is the case.  

Scott

On Tue, Apr 7, 2009 at 5:58 AM, Srivastava, Rajeev Kumar (Rajeev) <srivastava@xxxxxxxxx> wrote:

Hi,

 

I recently upgraded resiprocate library to 1.4.1 form 1.1 for one of my projects(Windows only).

After that TLS is not getting enabled.

 

<code snip>

 

      Security* pSecurity = new Security ( "..\etc" );
      SipStack* pSipStack = new SipStack ( pSecurity );
      StackThread* pStackThread = new StackThread ( *pSipStack );
      pSipStack->addTransport ( TLS, 
                                                       nTlsPort, 
                                                       V4,
                                                       StunDisabled,
                                                       Data::Empty,
                                                       Data::from ( strDomain ) );

      pSipStack->addTransport ( TCP, nTcpPort);

      pSipStack->addTransport ( TCP, nUdpPort);

      pStackThread->run ();

</snip>

 

This same piece of code is working fine with the same certificate with reSIProcate 1.1.

But it is not working with reSIProcate 1.4.1

 

I am attaching WireShark logs for reference.

 

Is there any change in SSL implementation and do I need to use it in a different manner now?

Do let me know if you need any more information for helping out.

 

Thanks,

~ Rajeev

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/