Skip to main content


Certificate requirements are found in several areas of Freeswitch, and it's optional in a lot of other places. It's not always obvious how to manage your certificate files, for instance where to put them, what the format should be and how to configure Freeswitch to use them properly. This page tries to clarify as much as possible about this. It also tries to explain some general things about the topic. The goal of the page is NOT to explain how the security of some module or protocol actually works. That's a thin line of course, but try to put in depth explanation of something like that in the home of that particular topic.

Click here to expand Table of Contents

Encryption based on SSL or TLS

SSL (Secure Sockets Layer) and it's successor TLS (Transport Layer Security) are all about encrypting data flowing between two hosts. Because it's been the standard in security on the internet since a lot of years it's also used for security in a lof of the protocols supported by Freeswitch.

There are plenty of 'certs for dummies' pages, please look there for the basics.

Some protocols in Freeswitch use the PKI way of doing things, others just create a trust relationship using certificates on the fly to secure communication.

Free Test Certificates

Let's Encrypt offers free short-term certificates good for testing a new FreeSWITCH™ instance with secure communications.

Securing SIP


ZRTP ZRTP IS NOW DEPREICATED and will be removed out of the docs


Most of the times using WebRTC the client is a internet browser. Internet browsers use PKI all the time, so WebRTC uses it too. At the time of writing Chrome, Firefox and Opera support WebRTC natively. Several Internet Explorer plugins are available.

The connection between the browser and Freeswitch when using WebRTC is based on websockets. Websockets can be used with (wss) and without (ws) encryption. The starting point of a websocket connection is a web page, served by a webserver. It's more convenient to serve the page using https, because the browsers will be more acceptant in remembering the user gave permission to use the mic or the cam from the computer used; when using standard http the browser will ask every time if it's ok. Firefox has a strict policy; if the websocket connection is initiated by a https page, it is mandatory the websocket connection is based on wss.

WebRTC does not work properly with self–signed certs. Chrome will not even tell you why when it refuses them. This is why a proper certificate is essential even when testing WebRTC. See Let's Encrypt above.


To send an INVITE to a WebRTC client or if you just need to send a call using DTLS encryption. For example, you are using Linphone with DTLS as FreeSWITCH clients or in case you need to originate a WebRTC call, but you are not calling a SIP UA that is registered with FS (if the UA is registered with FS, FS knows it should originate a WebRTC call).


# In the origination vars (commands originate or bridge) add:
# for example:
<action application="bridge" data="{media_webrtc=true}sofia/internal/"/>

To avoid delays in call setup, configure STUN to offer the correct candidates. Otherwise, FreeSWITCH must wait to auto-adjust which is slow and unreliable, and therefore not recommended.