Is it safe to rename created certs after creation?

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:

  • aaaaaauser1
  • aaaaaauser2
  • aaaaaauser3

While I would like to have the following instead:

  • abcuser1
  • defuser2
  • xyzuser3

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.


I’ve did some testing on my own and come to the following conclusion:

The web-UI doesn’t provide any renaming and if renaming is done low-level, changing individual details of the renamed connection might stop working because of checking the connection name again. Though this might be something one can easily live with.

Besides that, it seems to me that changing entries in the file “ovpnconfig” with some text editor and renaming the corresponding certificate files themself is enough to implement some naming scheme. Directly after both entities have been renamed in my tests to e.g. use an underscore, that was shown in reloaded web-UI without any problems. Additionally, the download buttons for certs, config etc. of the OVPN-connection worked instantly as well. I DID NOT rename any friendly name in the certs or alike and depending on the used common name in the cert (Bug 12641), showing the online status of some connection/user worked as well.

To make things a bit worse, there’s an additional directory of interest I didn’t recognize before: “/var/ipfire/ovpn/ccd” That contains additional configs per created connection, but doesn’t use the connection name as file name, but the common name of the created certificate. While that makes sense because that is the only thing presented to OpenVPN during establishing the connection, one needs to keep that in mind. Especially because the connection name implements different naming restrictions than the common name. :-/ In the end, the common name is what gets stored in “ovpnconfig” as well.

I’ve filed the following bugs in this context:


No, it isn’t safe to do this.

Yes, the common name of the certificate matters and you would have to change that, too. That isn’t possible, so the option you have is to revoke the certificate and create a new one with the name you want.


If the configuration file cannot be read you might not be able to view, edit or delete connections and probably won’t be able to connect any more.

I do not think that this was very helpful. First of all, they are not bugs. Secondly you have been asking questions to which nobody found the time to reply now and you jumped to (presumably wrong) conclusions.

As stated in those tickets, I would be happy to merge patches, but I do not think that any other user would benefit from your proposed changes.

1 Like

How does it matter? I didn’t need to rename it and it even allows the characters not allowed for connection names, like “", “-” etc., so one can easily implement a pretty good naming scheme with the CN right from the start. I’ve chosen to use “-” as delimiter, because "” doesn’t work properly currently. In the end, with a CN like “ams-tschoening”, I really only needed to modify “ovpnconfig” and rename the created cert files and things seem to work very well.

I do not think that this was very helpful. First of all, they are not bugs.

You are using Bugzilla and Bugzilla maintains bugs, even for enhancements or ideas or … In case of GitHub I would e.g. have said issues, regardless GH as well supports enhancements, discussions etc.

Secondly you have been asking questions to which nobody found the time to reply now and you jumped to (presumably wrong) conclusions.

I simply described what I did to get a working result and everyone is free to make their mind if they want to follow that approach or not.