I’ve been trying to create a new OpenVPN connection so it works with OpenSSL 3 to replace one I’ve been using until now. I’m on IPFire update 180.
I have an OpenVPN connection, let’s say called abc. I delete this connection. I try to create a new connection with the same name abc. It fails, telling me “a connection with this common name already exists”. I tried grepping all files and can’t find where this info could be stored.
Surely that’s a bug?
To make matters worse, before stumbling on the connection name, ipfire already fires up openssl which creates the certificate in /var/ipfire/ovpn/certs and updates the index.txt file with the hostname/organization name, so changing the connection name and pressing save now results in OpenSSL error 256 (by now my favourite error by far). Perhaps it should check if it can make the connection before openssl does its thing?
I’ve been trying to do this for an hour now, it really is much harder than it has to be.
I have just tried and I can’t reproduce your problem.
I created a new connection called testing with the remark testing and the hostname testing and password testing.
That created with no problem.
I then deleted that connection and re-added the same connection with exactly the same entries for each line and it was created without any problem.
The connection info is stored in
/var/ipfire/ovpn/ovpnconfig
You can check in there to see if the hostname or connection name that you are trying to use is already used by another connection.
Both the connection name and the certificate hostname need to be unique.
If you are getting the openssl 256 error then look in
/var/log/httpd/error_log and it will show more details on the issue that caused the error.
If the error is
A challenge password []:An optional company name []:Cannot write random bytes:
4097A65AC7790000:error:12000079:random number generator:RAND_write_file:Cannot open file:crypto/rand/randfile.c:240:Filename=/var/ipfire/ovpn/ca/.rnd
Oh. Silly me. “common name” obviously refers to OpenSSL’s CN. I somehow was convinced this was ipfire’s connection name.
So it’s actually that the error message is unclear. IPFire’s CN field is labeled “User’s full name or system hostname:”. The words “common name” do not appear anywhere on the page, so it’s not clear what the problematic name is.
I was indeed trying to add a certificate with the same CN as an existing one, but with a different O.
Still, even though the connection is not created, OpenSSL still creates a certificate and updates index.txt with the CN/O name pair (and the CN is the same as the other CN in there already) and this is why the second time I was trying to add the connection I was getting error 256. Is this correct behaviour?
If you are finding the common name in the index.txt file what is the letter at the start of the row. If that is V then the certificate is valid and existing. I have some old common name versions in my index.txt but they have R at the start of the line. These are certificates that have been released. The info is kept in index.,txt but that common name can be re-used and then gets a new index number.
I added a new connection that used a common name that was listed in index.txt but with an R at the start of the line. I was able to create this connection with no problems and the new certificate was added to the index.txt with a V at the start of the line.
The number of entries in index.txt with a V at the start of the line should match the number of connection entries that you have created.
If there are more lines starting with V in the index.txt than number of created connections then something must have got corrupted somewhere along the way or the deletion of the connection must have been interrupted and not all the information correctly updated.
Deleting my three new connections I created resulted in the removal of the cert/p12 files and also the changing of the V to an R in the index.txt file
Ah, crap. I edited the post instead of making a new one somehow. The contents that should be here is basically repeated in the bug I filed, link 2 posts down.
Thanks very much for the clear description of the steps you took.
I have been able to reproduce what you are experiencing. The code will need to be looked at in detail to see why this is happening and how to correct it.
This should not be happening. Please raise a bug in the IPFire bugzilla.
4312 # Check if there is no other entry with this common name
4313 if ((! $cgiparams{'KEY'}) && ($cgiparams{'AUTH'} ne 'psk')) {
4314 foreach my $key (keys %confighash) {
4315 if ($confighash{$key}[2] eq $cgiparams{'CERT_NAME'}) {
unlink ("${General::swroot}/ovpn/certs/$cgiparams{'CERT_NAME'}cert.pem");
4316 $errormessage = $Lang::tr{'a connection with this common name already exists'};
4317 goto VPNCONF_ERROR;
4318 }
4319 }
4320 }
might be a possibility? Line numbers are included, change have no line number. I think index.txt will also not be written if the ‘*.cert.pem’ has been unlinked but this should better be tested. Also this check might be a kind of old since it checks also for a PSK which are since decades disabled on IPFire.
The idea from @dammarin according to the “Common Name” hint in langs in Bugzilla might be indeed very useful i think.
You can do an unlink, but also it would totally be possible to check for the CN being a duplicate before creating the certificate. $cgiparams{‘CERT_NAME’} already exists, as far as I can see it, before line 4229, so putting lines 4312-4320 at line 4228 should possibly solve the problem? I could also be completely wrong, ofc.
I can’t even begin to guess what PSK is, but the check obviously returns true.
BTW, is it a problem if the CN is there more than once? If it’s a hostname then maybe yeah, but if it’s a “user’s full name” it should be fine? After all, the same user might have a few devices they’d want to connect to the VPN, also at the same time.
