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@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@freeswitch.org> wrote:
> How art thou generated the certs?
>
> On Aug 21, 2013, at 3:38 PM, Kristian Kielhofner <kris@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@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
>
>
> _________________________________________________________________________
> 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
>

--
Kristian Kielhofner

--
Kristian Kielhofner