IPFire seems to store newly created certificates in the directory “/var/ipfire/ovpn/certs” and seems to track the created names and some additional details for the web-UI in the file “/var/ipfire/ovpn/ovpnconfig”. Both files seems to be mapped by file names of the created certs in the end. Additionally, the certs itself seem to contain the name of the newly created connection/cert as some attribute named “friendlyName”. So it seems there are three places using the same one name to map things to each other.
I need to maintain an IPFire which some former employee of my company initially created and issued some OVPN connections using a naming scheme I don’t like too much. It seems that the web-UI restricts the number of characters for connection names and the current one uses a pretty long, not too useful prefix. OTOH, I need to provide connections for different users of different companies and would like to group those different companies using a shorter prefix.
Some example of what I have right now:
While I would like to have the following instead:
In the end, it’s only some file names and entries in some text files in theory, which could easily be modified manually on the shell. Though, I’m not sure about e.g. how enabled/disabled connections are recognized by OVPN and mapped to e.g. “friendlyName” in individual certs, if at all. Because “ovpnconfig” does contain a column for maintaining the status of a connection (“on” vs. “off”), so this needs to be mapped to provided certs during establishing a connection, to file names of certs etc.
So, is it safe to only rename cert files and their counterpart in “ovpnconfig” or do the individual certs need to be changed as well e.g. because of embedded “friendlyName”?
Are there any other files involved which would need to be modified?
Does the web-UI implement some process to rename connections/certs etc.?
What happens to existing and new connections when I’m doing something wrong to those two files and certs, connections and configs can’t be mapped properly anymore? I guess at least new connections simply fail, because IPFire can’t know if those are enabled or not.