This is what I had to do to get TLS working for  me...


In order to get client authenticated TLS to work between 2 FreeSWITCH servers, I had to add a "transport=tls" parameter to the dial string of the outbound call:

 

            ex.  sofia/sip-ua/sips:10.191.210.23:5081;transport=tls

 

Without this parameter, the UAC does not add a "transport=tls" parameter to the contact address of its initial INVITE request.  This seems to cause the UAS to try to send all its subsequent requests (such as a BYE) over UDP instead of TLS.

 

Also, generating the public certificate and private key store files using FreeSWITCH's "gentls_cert" script as described in "http://wiki.freeswitch.org/wiki/SIP_TLS" won't work by default for client authenticated TLS.  This is because the script generates the certs with attributes making them specific for either the server side or client side of a TLS handshake.  The TLS handshake will fail Purpose Validation if you try to configure a UAC with a cert that was generated specifically for a server.  To get around this, I had to comment out the "nsCertType" and "extendedKeyUsage" attributes from the "gentls_cert" script.


-JP



On Tue, Mar 25, 2014 at 5:05 PM, JP <jaykris@gmail.com> wrote:
Do you mean to say that the UAC need only send to "sip:<ip>:<tls_port>;transport=tcp" and not to "sips"?

I tried tweaking the parameters you mentioned in several different ways, but the contact address from the UAS always comes with "transport=udp".  Is this my problem? 


On Tue, Mar 25, 2014 at 10:22 AM, Michael Jerris <mike@jerris.com> wrote:
sips: should not make a difference, however.. take a look at bind-params and tls-bind-params


On Mar 25, 2014, at 1:15 PM, JP <jaykris@gmail.com> wrote:

Is there any way to specify the full contact header in a UA profile that the SIP stack will use when formulating messages?  Specifically, have it use "sips" instead of "sip" as the protocol scheme? 

 

I'm trying to establish an INVITE dialog between 2 FreeSWITCH servers using a client authenticated TLS handshake.

 

To accomplish this, I've created 2 UA profiles on both servers - one to fulfill the role of the UAC (i.e. tls-uac.xml) and one to implement the UAS (i.e. tls-uas.xml).  Here are the relevant parameters from both profiles:

 

tls-uac.xml:

 

            <param name="sip-port" value="5081"/>

 

            <param name="tls" value="true"/>

 

            <param name="tls-only" value="true"/>

 

            <param name="tls-sip-port" value="5082"/>

 

            <param name="tls-cert-dir" value="$${base_dir}/conf/tls/uac"/>

 

tls-uas.xml:

 

            <param name="sip-port" value="5081"/>

 

            <param name="tls" value="true"/>

 

            <param name="tls-only" value="true"/>

 

            <param name="tls-sip-port" value="5081"/>

 

            <param name="tls-cert-dir" value="$${base_dir}/conf/tls/uas"/>

 

The problem already starts when "tls-uac" sends a non-secure SIP URI in the contact header of its initial INVITE request (i.e. sip:mod_sofia@10.191.210.150:5081).  But the more immediate issue is that "tls-uas" also responds with a non-secure SIP URI in the contact header of its final response (i.e. sip:14086805675@10.191.210.151:5081;transport=udp).  This causes "tls-uac" to send its ACK to the right port number (i.e. 5081) but on the wrong transport (i.e. UDP instead of TCP/TLS).

 

I've seen in the FS documentation that there are ways to manipulate the contact header through the dial plan, but I'd really prefer not to do it this way.  Any suggestions?

 

Thanks

JP

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org