Self-signed certificate should only be generated if no external cert is specified

[mumble-voip]

This is about murmur on GNU/Linux

If a certificate is specified in the config file, but it has a wrong order of helper cert and cert, or a typo in the path or there is an permission error and the cert fails to load, the server is just starting up any way and generates a self signed cert which is stored in the database.

This is a really stupid behaviour, the reason is obvious:

• If the specified cert couldn't be loaded, this has to stop the starting up process. The Admin has chosen to use his own cert by specifying this in the config file, murmurd has to respect the users choice and not to ignore this choice by making it's own decisions.
• As long as you don't look in the log file the server seems to start up completely normal, but the cert you want is just gone.
• The self signed cert that is generate by murmurd has to be delete out of the database by calling murmurd with -wipessl, only than you can use your own cert again. This is not even noted in the manpage of murmurd. You have to search the internet to even find this way go back to the configuration you want. (Are want the people to use this self generated cert by force?)

This ticket has been migrated from sourceforge. It is thus missing some details like original creator etc. The original is at https://sourceforge.net/p/mumble/bugs/1014/ .

[Kissaki]

this has to stop the starting up process

Well, not necessarily. With every user setting you can either fail on problems or use a plausible/useful default instead. In this case I agree though. If the specified cert can not be loaded the startup should probably fail.

The self signed cert that is generate by murmurd has to be delete out of the database by calling murmurd with -wipessl

It seems you are not familiar with Murmurs ini configuration and vserver concept. The ini file provides default values for the potentially multiple vservers (servers you can connect to) that the process runs. (This way you can for example provide a default welcome text for all vservers, but still specify specific ones for the individual vservers overriding the default.) So I guess you set your certificate only via the murmur.ini. Thus, only the default is set while the vserver already has a specific self-generated certificate, thus not using the default any more. Wiping this certificate will make murmur use the default again.

I guess the wiki could really use a how to own-cert, if it does not provide one yet.

[Kissaki]

Looking at the code, --wipessl is not necessary for replacing an autogenerated cert with one specified in the ini, at least in our development snapshots/1.3.0, see Cert.cpp#L137

We still log failure to load the cert specified in the ini, and we still create a new autogenerated one in that case; Cert.cppL165.

[davepfeiffer]

After looking into it further, I realized that I'm using a very outdated version of murmur (~1.2.9) and it was not logging use of the autogenerated cert without the verbose option. I'm not sure if this is current behavior. I agree with the your previous sentiment that if a user is competent enough to specify their own cert/key pair, murmur should not try to recover from failing to load them.

[Krzmbrzl]

@Kissaki did I understand it correctly that this is resolved in 1.3?

[Kissaki]

My comment only talks about the state in 1.3, not about whether it changed or not.

[ghost]

Is this still an issue in 1.4?

[Krzmbrzl]

Yep.