<div dir="ltr"><p class="MsoNormal">> This is normal.</p><p class="MsoNormal">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 <a href="http://wiki.freeswitch.org/wiki/SIP_TLS">http://wiki.freeswitch.org/wiki/SIP_TLS</a>
and <a href="https://wiki.freeswitch.org/wiki/Sofia-SIP">https://wiki.freeswitch.org/wiki/Sofia-SIP</a>.
If there are additional resources that cover this feature in more detail
please let me know. <br></p><p class="MsoNormal"><br></p><p class="MsoNormal">> This is strange. What was on the other side?</p><p class="MsoNormal"></p><div class="gmail_extra"><span style="font-size:12pt;font-family:'Times New Roman',serif">Both endpoints are
FreeSWITCH servers.</span></div><div class="gmail_extra"><p class="MsoNormal"><br></p><p class="MsoNormal">> nsCertType checking is largely deprecated (only OpenVPN uses
it AFAIK). Typically the standard client and server OIDs are used instead</p><p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New Roman',serif">I set the
"tls-version" parameter to "tlsv1" in the SIP profiles of
both FreeSWITCH servers. Do you recommend using something else?</span><br></p><p class="MsoNormal"><br></p><p class="MsoNormal">> 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.</p><p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New Roman',serif">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. </span><br></p><p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New Roman',serif"><br></span></p><p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New Roman',serif">-JP</span></p>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New Roman',serif"><br></span></p><p class="MsoNormal"></p><div class="gmail_quote">On Mon, Mar 31, 2014 at 12:28 PM, Kristian Kielhofner <span dir="ltr"><<a href="mailto:kris@kriskinc.com" target="_blank">kris@kriskinc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Mon, Mar 31, 2014 at 3:15 PM, JP <<a href="mailto:jaykris@gmail.com">jaykris@gmail.com</a>> wrote:<br>
> This is what I had to do to get TLS working for me...<br>
><br>
><br>
> In order to get client authenticated TLS to work between 2 FreeSWITCH<br>
> servers, I had to add a "transport=tls" parameter to the dial string of the<br>
> outbound call:<br>
><br>
><br>
><br>
> ex. sofia/sip-ua/sips:10.191.210.23:5081;transport=tls<br>
><br>
><br>
><br>
> Without this parameter, the UAC does not add a "transport=tls" parameter to<br>
> the contact address of its initial INVITE request. This seems to cause the<br>
> UAS to try to send all its subsequent requests (such as a BYE) over UDP<br>
> instead of TLS.<br>
<br>
</div> This is normal.<br>
<div class=""><br>
> Also, generating the public certificate and private key store files using<br>
> FreeSWITCH's "gentls_cert" script as described in<br>
> "<a href="http://wiki.freeswitch.org/wiki/SIP_TLS" target="_blank">http://wiki.freeswitch.org/wiki/SIP_TLS</a>" won't work by default for client<br>
> authenticated TLS. This is because the script generates the certs with<br>
> attributes making them specific for either the server side or client side of<br>
> a TLS handshake. The TLS handshake will fail Purpose Validation if you try<br>
> to configure a UAC with a cert that was generated specifically for a server.<br>
> To get around this, I had to comment out the "nsCertType" and<br>
> "extendedKeyUsage" attributes from the "gentls_cert" script.<br>
<br>
</div> This is strange. What was on the other side?<br>
<br>
nsCertType checking is largely deprecated (only OpenVPN uses it<br>
AFAIK). Typically the standard client and server OIDs are used<br>
instead:<br>
<br>
<a href="http://www.openssl.org/docs/apps/x509.html#CERTIFICATE_EXTENSIONS" target="_blank">http://www.openssl.org/docs/apps/x509.html#CERTIFICATE_EXTENSIONS</a><br>
<br>
IIRC the FreeSWITCH gentls_cert script properly sets both client and<br>
server purpose, which is what you would expect because the cert is set<br>
on a per profile basis and depending on call direction any given<br>
profile can be a SIP UAS or SIP UAC.<br>
<span class=""><font color="#888888"><br>
--<br>
Kristian Kielhofner<br>
</font></span><div class=""><div class="h5"><br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br></div></div>