[sr-dev] RFC: about the self signed tls certificates

Fred Posner fred at palner.com
Wed Jul 22 17:49:32 CEST 2015


I think this is a good idea. My only suggestion would be to perhaps add
a reminder after make (or make install) for any packages that will need
additional installation; such as db_ or (if modified tls).

For example, if tls and db_mysql are installed, a message echoed to
terminal such as "Please remember to run kamdbctl create" and "Please
remember to run kamctl tls generate-certificate" etc.

--fred

On 07/20/2015 02:58 PM, Daniel-Constantin Mierla wrote:
> Hello,
> 
> (cross-posting as it impacts users as well)
> 
> Currently we generate and install the TLS self-signed certificates when
> tls module is installed, including them in the debian packages (and I
> guess in rpms).
> 
> Debian has a policy of reproducible builds, meaning that from same
> source tree snapshot the same binary packages should result.
> 
> Even more important considering the impact on security, it would be
> better that the certificates are generated locally on the installation
> server, to be distinct. Right now, people relying on default
> installation config/certificates (and I guess there are many, at least
> in testing phase), are exposed to eavesdropping, because the private key
> is available in public packages.
> 
> My proposal is to move generation of self signed certificates to kamctl.
> There can be a kamctl.tls file to be deployed by the tls package (same
> is done by kamctl.mysql, being part of mysql package), which should add
> a new group of commands, among them something like:
> 
> kamctl tls generate-certificate
> 
> The drawback is that before enabling tls and starting kamailio, one has
> to run the above command. We can document that in tls module readme and
> in kamailio.cfg in the comments related to WITH_TLS define.
> 
> Anyone with comments, pros/cons?
> 
> Other suggestions on how to address the reproducible builds as well as
> solve the security issue for the default installation?
> 
> Cheers,
> Daniel
> 



More information about the sr-dev mailing list