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

[Kristian Kielhofner]

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