[Freeswitch-users] SIP Contact Header Issue When Using TLS

[JP]

> This is normal.

Setting "transport=tls" for the dial string doesn't appear to be clearly
documented anywhere.  I tried this purely out of intuition since
"transport=tcp" (which is documented) didn't seem to work.  The two main
resources I've been using are http://wiki.freeswitch.org/wiki/SIP_TLS and
https://wiki.freeswitch.org/wiki/Sofia-SIP.  If there are additional
resources that cover this feature in more detail please let me know.


> This is strange. What was on the other side?

Both endpoints are FreeSWITCH servers.


> nsCertType checking is largely deprecated (only OpenVPN uses it AFAIK).
Typically the standard client and server OIDs are used instead

I set the "tls-version" parameter to "tlsv1" in the SIP profiles of both
FreeSWITCH servers.  Do you recommend using something else?


> IIRC the FreeSWITCH gentls_cert script properly sets both client and
server purpose, which is what you would expect because the cert is set on a
per profile basis and depending on call direction any given profile can be
a SIP UAS or SIP UAC.

The script appears to have 3 options: generating the "root" CA signing cert
(i.e. setup), generating a server cert (i.e. create_server), and a client
cert (i.e. create_client).  There is also a "create" option but this just
appears to be doing the same thing as "create_server".  As you point out, a
given user agent can act as a UAC or UAS depending on the direction of the
request.  In my case, what appears to be happening is that the call gets
setup completely over the same TCP connection requiring just one TLS
handshake.  However, when the hangup is initiated from the terminating end
of the call, the FreeSWITCH that was previously fulfilling the role of the
UAS during call setup is now acting as the UAC and tries to setup a second
TCP/TLS connection for sending the BYE.  Since it is configured with a
server cert - that is, a cert generated using the "create_server" option -
it appears to fail purpose validation when the UAS challenges it for its
cert.


-JP


On Mon, Mar 31, 2014 at 12:28 PM, Kristian Kielhofner <kris at kriskinc.com>wrote:

> On Mon, Mar 31, 2014 at 3:15 PM, JP <jaykris at gmail.com> wrote:
> > 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.
>
>   This is normal.
>
> > 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.
>
>   This is strange. What was on the other side?
>
>   nsCertType checking is largely deprecated (only OpenVPN uses it
> AFAIK). Typically the standard client and server OIDs are used
> instead:
>
> http://www.openssl.org/docs/apps/x509.html#CERTIFICATE_EXTENSIONS
>
>   IIRC the FreeSWITCH gentls_cert script properly sets both client and
> server purpose, which is what you would expect because the cert is set
> on a per profile basis and depending on call direction any given
> profile can be a SIP UAS or SIP UAC.
>
> --
> Kristian Kielhofner
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140331/7b80ba51/attachment-0001.html