[Freeswitch-users] TLS with FreeSWITCH and Kamailio

[Kristian Kielhofner]

Answering my own post:

After cranking up Sofia debugging and reading through source Sofia really
wants to see "-extensions server" on the "server" generated cert in this
case, which makes sense but it's also problematic because any SIP UA can be
a "server" or "client" with different keys (with full validation) and as
far as I can tell FreeSWITCH only allows for one key+cert per profile
(which can be a "client" or "server").

Kamailio provides for completely separate client and server TLS
configuration, including key, cert, CA, CRL, etc, etc.

Is there a mechanism to provide different client and server certs per
profile with Sofia?  It looks like that's the only way this is going to
work.

Thanks!


On Wed, Aug 21, 2013 at 5:22 PM, Kristian Kielhofner <kris at kriskinc.com>wrote:

> Good question!
>
> I've tried a variety of certs, going all the way back to the CA.  I
> started with your gentls_cert script and eventually moved to the
> openvpn-style "easy-rsa" package.  I will tell you that using
> identical certs with a TLS-capable pjsip pjsua client results in a
> successful TLS connection to Kamailio (using the same CA cert, client
> cert, and client key used in FreeSWITCH).  Of course I'm not changing
> the config in Kamailio either.
>
> On Wed, Aug 21, 2013 at 5:03 PM, Brian West <brian at freeswitch.org> wrote:
> > How art thou generated the certs?
> >
> > On Aug 21, 2013, at 3:38 PM, Kristian Kielhofner <kris at kriskinc.com>
> wrote:
> >
> >> Hello,
> >>
> >>  I'm trying to get TLS cert validation between FreeSWITCH (client)
> >> and Kamailio (server) up and running.  Here's my config/setup so far:
> >>
> >> FreeSWITCH 1.2.12 (client) configured with:
> >>
> >>    <!-- TLS: disabled by default, set to "true" to enable -->
> >>    <param name="tls" value="true"/>
> >>    <!-- additional bind parameters for TLS -->
> >>    <param name="tls-bind-params" value="transport=tls"/>
> >>    <!-- Port to listen on for TLS requests. (5061 will be used if
> >> unspecified) -->
> >>    <param name="tls-sip-port" value="5081"/>
> >>    <!-- Location of the agent.pem and cafile.pem ssl certificates
> >> (needed for TLS server) -->
> >>    <param name="tls-cert-dir" value="[my cert dir]"/>
> >>    <!-- TLS version ("sslv23" (default), "tlsv1"). NOTE: Phones may
> >> not work with TLSv1 -->
> >>    <param name="tls-version" value="tlsv1"/>
> >>    <param name="tls-verify-policy" value="out"/>
> >>
> >> I have a gateway configured with ;transport=tls
> >>
> >> Kamailio 4.0 (also tried 4.1, etc) configured with (tls.cfg):
> >>
> >> [server:default]
> >> method = TLSv1
> >> verify_certificate = no
> >> require_certificate = yes
> >> private_key = /etc/kamailio/generic-sip.key
> >> certificate = /etc/kamailio/generic-sip.pem
> >> ca_list = /etc/kamailio/generic-cacert.pem
> >> cipher_list = AES
> >>
> >>  I'm using my own CA with self-signed certs.  I've verified that they
> >> check out by comparing the modulus on the cert and key pairs and
> >> verifying the CA chain with 'openssl verify ...'.
> >>
> >>  When I run without tls-verify-policy=none and require_certificate=no
> >> everything is golden and TLS works all day long.  However, this is
> >> less than ideal and I'd like to at least make sure that my TLS clients
> >> are presenting a valid cert.  Unfortunately when FS tries to connect
> >> to Kamailio it reports the following errors:
> >>
> >> ERROR: tls [tls_server.c:1190]: TLS accept:error:140890B2:SSL
> >> routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
> >> ERROR: <core> [tcp_read.c:1275]: ERROR: tcp_read_req: error reading
> >>
> >>  What's interesting is that FreeSWITCH reports a successful
> >> registration and seems to exchange OPTIONS pings (over UDP!) with the
> >> remote Kamailio instance.  However, Kamailio does not show the
> >> endpoint as registered (verified with 'kamctl ul show').  That seems
> >> like a bug and worthy of a JIRA but my main concern at this point is
> >> getting TLS with certificate validation up and running.
> >>
> >>  Any ideas?  Thanks!
> >>
> >> --
> >> 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
> >
> >
> > _________________________________________________________________________
> > 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
> >
>
>
>
> --
> Kristian Kielhofner
>



-- 
Kristian Kielhofner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130822/e996f6df/attachment.html