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.i... 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