> 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?
> 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 3:15 PM, JP <jaykris@gmail.com> wrote:This is normal.
> 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 strange. What was on the other side?
> 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.
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@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