Home / OpenSIPS / Using TLS in OpenSIPS v2.2.x

Using TLS in OpenSIPS v2.2.x

by Smartvox on March 16, 2017

I’ve been looking at TLS connections to OpenSIPS recently. Support for TLS existed in version 1, but the configuration changed significantly in version 2.

Using version 2.2.3, you will need to include a listen statement a bit like this:


Load the following modules, in addition to the usual ones:

loadmodule "tls_mgm.so"
loadmodule "proto_tls.so"

…and configure various parameters in the tls_mgm module using modparam statements, including:

modparam("tls_mgm", "tls_method", "SSLv23")        # This option seems to work nicely in most cases
modparam("tls_mgm", "certificate", "/etc/opensips/tls/mycerts/mycertfile.pem")  # Path to your server certificate file
modparam("tls_mgm", "private_key", "/etc/opensips/tls/mycerts/mykeyfile.pem")   # The path to your key certificate file

I was using self-signed certificates (.pem files), having previously set up my own Certificate Authority. If you are trying something similar, make sure you override SHA-1 encryption which openssl is likely to set as the default (it is no longer considered secure) and at least use SHA256. I did this by editing my openssl.cnf file and changing this line to

default_md = sha256
(previously it said default_md=md5)

You can, I believe, also set the desired encryption as a command line argument when you run openssl from the command line.

For my test rig, I added a modparam statement to define the “ca_list” parameter. This defines the path to a file containing the CA’s certificate – again this was a .pem file. You may need this for commercially issued certs too.

My settings for certificate verification requirements were fairly easy-going, as follows:

modparam("tls_mgm", "verify_cert", "1")
modparam("tls_mgm", "require_cert", "0")

There is nothing special you do in the route blocks, but if you are setting up OpenSIPS as a Registrar server, a useful tip is to set the global parameter “tcp_connection_lifetime” to a value that is just larger than the maximum registration expire time you expect to see. Without this, the TLS connection established during registration is likely to be dropped before the next re-register happens. That, in turn, is likely to cause problems with requests sent to a UA behind NAT or behind a firewall (most are) meaning that the UA can make calls but cannot always receive them.

  What did you think of this article? Please vote by clicking a coloured button
(0%) (0%) (0%) (0%)

Previous post: