On Mon, Mar 31, 2014 at 3:15 PM, JP <jaykris@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