[Freeswitch-users] tls SIP Trunk in Freeswitch

[Claus Andersen]

On Wed, 19 Jun 2013, mehroz wrote:

> I am also confused ,  which certs and from which server need to be imported
> to the other server.
> Either cafile.pem of FS1 has to go to FS2, or cafile.pem of FS2 has to move
> over FS1.


The cert part of it works like regular SSL/TLS. Most people have already 
tried this with web servers and it is the same thing.

Try this link for a visual understanding of how certificate chains work:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=%2Fcom.ibm.mq.csqzas.doc%2Fsy10600_.htm

Your SSL/TLS library will have a default list of trusted root authorities. 
In my experience this is the crucial piece of information people are 
missing when they try to understand X.509 and friends.

There are 3 typical use cases:

A) Well known certificate:
If you request a certificate for FS1 from a "well known vendor" the magic 
happens because the vendors root certificate is already listed as a 
trusted root authority. In that case FS2 (or any other host on the 
Internet) will verify the certificate presented by FS1 in the list of 
trusted roots (and intermediates).

B) Private root CA:
Som people choose to deploy their own root certificate authority. This 
authority allows you to easily create your own certificates. Your root 
certificate is however not known in any default lists. You then need to 
import your CA everywhere you need to use these certificate. If you 
request a certificate for FS1 from your own CA it will only be valid on 
those systems where you have imported your own root. You only have to 
import your root once and then all your certificates can be verified. In 
that case FS2 will accept the certificate presented by FS1 only if you 
have imported the root.

C) Self signed certificate:
Many examples are given using self signed certificate. When you generate a 
self signed certificate you have no root CA. No one will then be able to 
verify the certificate without knowing it. If you generate a self signed 
certificate on FS1 you need to furthermore import it into the certificate 
chain on whatever system which need to accept it. In that case FS2 will 
accept the certificate presented by FS1 only if you have already imported 
into the certificate chain on FS2.

Case A) Is the typical scenario if you need third parties you have no 
control over to trust FS1. This is the exact same thing you would do with 
a web server.

Case B) Is usually only for large enterprises who needs to easily deploy a 
lot of certificates which does not need to be trusted outside their own 
network. A very common example is when corporates deploy a PKI together 
with Windows Active Directory.

Case C) Self signing is usually only for testing. For very small and 
closed networks it is acceptable as well. Due to management it is often 
preferable to either use a well known certificate or to deploy your own CA 
for production.

This is a very high level description and I have not touched on private 
keys certificate types and what not. This is only meant as a high level 
introduction. You should read up on SSL, TLS and X.509 to get the full 
understanding. TLS is Transport Layer Security and is used in many 
different contexts.

So if we only have FS1 and FS2 we have the following options:

1) If FS2 is supposed to trust FS1:

Case A) Generate a certificate request on FS1. Bind the resulting 
certificate to the service (freeswitch) on FS1. FS2 will trust FS1 
automagically because of the default root CA list. As will any other 
server on the Internet.

Case B) Generate a certificate request on FS1. Bind the resulting 
certificate to the service (freeswitch) on FS1. On FS2 you need to import 
the root CA (and intermediate) certificates into the certificate chain. 
Every other server on you network where you have imported the root CA will 
automagically trust FS1. Servers who does not know of your root CA will 
not trust FS1.

Case C) Generate a self signed certificate on FS1. Bind the resulting 
certificate to the service (freeswitch) on FS1. On FS2 you need to import 
the certificate from FS1 to be able to recognize it. No other servers will 
trust FS1 unless you have imported that certificate.

2) If FS1 is supposed to trust FS2:
Case A) Generate a certificate request on FS2. Bind the resulting 
certificate to the service (freeswitch) on FS2. FS1 will trust FS2 
automagically because of the default root CA list. As will any other 
server on the Internet.

Case B) Generate a certificate request on FS2. Bind the resulting 
certificate to the service (freeswitch) on FS2. On FS1 you need to import 
the root CA (and intermediate) certificates into the certificate chain. 
Every other server on you network where you have imported the root CA will 
automagically trust FS2. Servers who does not know of your root CA will 
not trust FS2.

Case C) Generate a self signed certificate on FS2. Bind the resulting 
certificate to the service (freeswitch) on FS2. On FS1 you need to import 
the certificate from FS2 to be able to recognize it. No other servers will 
trust FS2 unless you have imported that certificate.


The examples in the wiki suggest that you create your own CA. If you are 
not used to working with certificates that can be really complex. In that 
case I would recommend using a well known certificate from CAcert or 
StartSSL. That saves you the hassle of having your own CA.

Kind Regards,
Claus Andersen