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
https://wiki.freeswitch.org/wiki/Sofia.conf.xml
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