https://www.opensips.org/Documentation/Tutorials-TLS-2-1

1.  Introduction

Configuring TLS can sometimes be time consuming, most times because of badly generated or used certificates. What this tutorial is trying to do is providing a basic TLS configuration for OpenSIPS which we know for sure that will work and be the entry point for future, more complicated, TLS setups. At first we will be trying to do the most important thing of all: generating some certificates which we can use to later configure OpenSIPS. If all you want to do is testing the TLS, you can always skip to section 2.4 Using OpenSIPS built-in certificates. The next step will be writing a script for OpenSIPS which will use TLS. After starting OpenSIPS, what we must do is testing that OpenSIPS works fine listening for TLS connections from UACs and creating new connections with UACs and debugging the handshake.

2.  Generating certificates

2.1  Overview

Before configuring OpenSIPS we need to have a CA and be able to sign certificates with this CA. In order to do this, we will configure a new CA and a user certificate signed by this CA. We will use OpenSIPS to achieve these goals, since it offers a very simple way to manage certificate related issues using opensipsctl script. Also, you can always create your own CA or set of certificates using the scripts provided by openSSL or by other means.

2.2  Creating the CA

Creating context

First thing we need to do is setup the context for our certificates to be created. Let’s say that you want to use $OPENSIPS_HOME/tls_cnf ($OPENSIPS_HOME represents the path to your OpenSIPS install). Create this folder (if it doesn’t exist) and inside create a folder named tls. Will explain later why we needed to do this.

Setting up ca.conf file

Next we need to generate our certificating authority, but first we need a configuration file for this, because based on this configuration file, OpenSIPS will know the details of your request. In this configuration file you can set the paths where the CA will be generated, validity, DN etc. For users who did this before, it looks similar to “openssl.cnf” file. You can find an example in $OPENSIPS_HOME/etc/tls/ca.conf. In this tutorial we only want to make it work, so we will use that file by copying it to our tls_cnf/tls folder.

Creating the CA

Now that we set up the context, we can create the CA. Go to your $OPENSIPS_HOME/scripts folder.

Here you should be able to find the opensipsctl script. Use the following command:

The rootCA parameter specifies to the script that you want to create a new certificating authority (the parameter cannot be changed). The last parameter specifies the folder where we want this CA to be installed, so we will choose the folder we set up earlier. 

After giving the command you will be requested to introduce a passphrase. We will use this passphrase later when we will create the certificates. The server certificate will consist of the certificate found in the new rootCA folder created $OPENSIPS_HOME/tls_cnf/tls/rootCA/cacert.pem, and the private key will be in $OPENSIPS_HOME/tls_cnf/tls/rootCA/private/cakey.pem.

2.3  Creating server and client certificates

To create a user certificate you will need to create request.conf and <user_name>.conf file in order to use opensipsctl. In this tutorial we will simply use the files provided by OpenSIPS in $OPENSIPS_HOME/etc/tls called request.conf and user.conf.

Next we have to go again to $OPENSIPS_HOME/scripts and use opensipsctl.

The third parameter’s meaning is the name of the user which must be the same as the <user_name>.conf file. So, for example, if we wanted the user alice, the file must have had the name alice.conf . The fourth parameter represents the path where you have the configuration files. Now, that we have created the certificates we can move to the following section, a script example to use TLS with OpenSIPS.

2.4  Using OpenSIPS built-in certificates

If all you want to do is testing, you can always use the certificates located in $OPENSIPS_HOME/etc/tls, but we strongly recommend to you not to use this certificates in real case scenarios, because, as you can imagine, everyone has access to them. Also notice that the passphrase with which the CA is configured is opensips. 
IMPORTANT: in the following sections we will refer to the folder where the certificates are located as $CERT_DIR, so none of the paths presented above are valid anymore, but we will keep the notations rootCA as the folder where the CA is installed and user where the user certificates are.

3. Script example

3.1 Overview

As you probably discovered, in OpenSIPS 2.1 the tls became a module, so now, every parameter we want to pass to TLS will be a modparam parameter. The scenario is very simple, UAC is trying to send an invite to an UAS by using OpenSIPS as a proxy, and both connections UAC<->OpenSIPS and OpenSIPS<->UAS are using encrypted data transfer, using TLS. So we will try to provide a basic TLS script configuration which tries to use basically all the configurable parameters of the TLS module, from which you can start building your own.

3.2 The listener

In order to accept TLS connections, OpenSIPS must have a TLS listener. In order to do this we have to include the following line in our script:

When OpenSIPS will start, you should be able to see the listener by entering the following command in your command line

where port is the port you gave to listen line in your script.

3.3 Including TLS module and setting the parameters

Since TLS became a module, now we need to insert the following line in the modules section

Since this is a test scenario, we only want to check that the TLS handshake works fine, so we won’t set parameters to enable certificate checking or ciphers. As OpenSIPS enables these checkings by default because a real TLS configuration must check the certificates, we will need to disable them.

We will need to specify the TLS method which will specify what type of protocol we will use. In this tutorial we will use “TLSv1”, but you can always use another one, see the full list in the module’s documentation section.

Also, in order for OpenSIPS to start, we need to configure some "global" certificates. We need to do this because we need a default match, if no domain is matched, we will need a default case, something to match everything, just like 0.0.0.0 route in routing tables. You can always jump over the following section 3.4 Setting up TLS domains directly to 3.5 Full script example, because they represent a more specific type of scripting, but it is recommended to read about server domains which allow you to use different settings on different listening interfaces.

 modparam("proto_tls", "certificate", "$CERT_DIR/rootCA/cacert.pem")           
 modparam("proto_tls", "private_key", "$CERT_DIR/rootCA/private/cakey.pem")    
 modparam("proto_tls", "ca_list", "$CERT_DIR/rootCA/cacert.pem")                
 modparam("proto_tls", "ca_dir", "$CERT_DIR/rootCA/")                

3.4 Setting up TLS domains

As specified in section 3.1 Overview, our scenario includes two TLS connections, one from the UAC to OpenSIPS and the second one from OpenSIPS to the UAS. Whereas in the first connection OpenSIPS will be the server side of the connection, in the second one it will be the client side so we need to define two different TLS domains.

 #first the  server domain
 modparam("proto_tls", "server_domain", "sv_dom=<your-ip-address>:<port>")           
 modparam("proto_tls", "certificate", "sv_dom:$CERT_DIR/rootCA/cacert.pem")           
 modparam("proto_tls", "private_key", "sv_dom:$CERT_DIR/rootCA/private/cakey.pem")    
 modparam("proto_tls", "ca_list", "sv_dom:$CERT_DIR/rootCA/cacert.pem")                

 #and the client domain                                                               
 modparam("proto_tls", "client_domain", "cl_dom=<UAS-ip-address>:<port>")            
 modparam("proto_tls", "certificate", "cl_dom:$CERT_DIR/user/user-cert.pem")          
 modparam("proto_tls", "private_key", "cl_dom:$CERT_DIR/user/user-privkey.pem")       
 modparam("proto_tls", "ca_list", 'cl_dom:$CERT_DIR/user/user-calist.pem")             

IMPORTANT: The ip address and port from the server domain must be the ones you set in the “listen” script line for OpenSIPS to match that domain. When OpenSIPS acts as client, the ip address and port must be the ones of the server (remote peer) with whom initiates the TLS handshake, so unless you do not know the remote address and port there is no need to define a client domain, default settings will be used.

3.5  Full script example

Now that we specified all we need to set in order to be able to use TLS both as a server and as a client we will specify here a full script (only the TLS part) in order to make things more clear. Basically it is all we explained in the previous sections of this chapter put together.

 #define the listener
 listen = tls:<your-ip-address>:<port>

 #set module path
 loadmodule “proto_tls.so”

 #set global tls parameters
 modparam("proto_tls", "verify_cert", "0")
 modparam("proto_tls", "require_cert", "0")
 modparam("proto_tls", "tls_method", "TLSv1")

 modparam("proto_tls", "certificate", "$CERT_DIR/rootCA/cacert.pem")           
 modparam("proto_tls", "private_key", "$CERT_DIR/rootCA/private/cakey.pem")    
 modparam("proto_tls", "ca_list", "$CERT_DIR/rootCA/cacert.pem")                
 modparam("proto_tls", "ca_dir", "$CERT_DIR/rootCA/")                


 #server domain
 modparam("proto_tls", "server_domain", "sv_dom=<your-ip-address>:<port>")
 modparam("proto_tls", "certificate", "sv_dom:$CERT_DIR/rootCA/cacert.pem")
 modparam("proto_tls", "private_key", "sv_dom:$CERT_DIR/rootCA/private/cakey.pem")
 modparam("proto_tls", "ca_list", "sv_dom:$CERT_DR/rootCA/cacert.pem")

 #client domain
 modparam("proto_tls", "client_domain", "cl_dom=<UAS-ip-address>:<port>")
 modparam("proto_tls", "certificate", "cl_dom:$CERT_DIR/user/user-cert.pem")
 modparam("proto_tls", "private_key", "cl_dom:$CERT_DIR/user/user-privkey.pem")
 modparam("proto_tls", "ca_list", "cl_dom:$CERT_DR/user/user-calist.pem")

4.  Troubleshooting

4.1 Overview

Now that we’ve set up OpenSIPS and started it, we need to do some debugging and see if everything works fine. There will be presented two ways to debug your TLS connection. First just verifying the TLS handshake with openSSL s_client and after this a more complex type of debugging which is teaching Wireshark to decrypt messages using the private key of the connection.

4.2 S_client simple testing

A very simple and fast method to see that the handshake works fine is the s_client tool that openSSL provides. The command for the script in the previous chapter looks like this

 openssl s_client -showcerts -debug -connect <your-ip-address>:<port> -no_ssl2 -bugs

The ip address and the port are the ones you have set earlier in the listen section of the script. If you want more advanced debugging, check the following section which tells you how to debug the tls connection using Wireshark.

4.3 Wireshark tracing

Wireshark allows us to catch the TLS handshake and also to decrypt the traffic, but in order to do this we must configure it to know the private keys of the connection. Go to Edit → Preferences → Protocols → SSL. Click the Edit button in RSA keys list section. Click the New button and add the ip address and port on which OpenSIPS is listening, the protocol (in our case sip) and in the Key File section search for the private key OpenSIPS uses for the connection ( for the example above $CERT_DIR/rootCA/private/cakey.pem). Save the configuration and then you can see both the TLS handshakes and the TCP messages that are being sent to and from OpenSIPS listening interface. 
IMPORTANT: Depending on your configuration, it might be necessary to configure both the private key of the server and the client in Wireshark!!!