Bug 13137

Summary: CU175 Testing - Existing n2n client connection created with openssl-1.1.1x fails to start with openssl-3.x
Product: IPFire Reporter: Adolf Belka <adolf.belka>
Component: ---Assignee: Adolf Belka <adolf.belka>
Status: CLOSED FIXED QA Contact:
Severity: Crash    
Priority: Will affect all users CC: michael.tremer, peter.mueller, ummeegge
Version: 2   
Hardware: all   
OS: All   
Bug Depends on:    
Bug Blocks: 11048    
Attachments: error message from n2n client when trying to connect

Description Adolf Belka 2023-05-31 18:11:04 UTC
Created attachment 1180 [details]
error message from n2n client when trying to connect

With an existing n2n connection where the .p12 certificate was created with openssl-1.1.1x then with openssl-3.x the client end of the tunnel fails to run.

Attached error message shows that the failure is fatal and the connection is not made.
Comment 1 Adolf Belka 2023-05-31 18:32:37 UTC
The use of the -legacy option with the openssl command is not usable in this case as the failure is not occurring due to any openssl command in ovpnmain.cgi

The problem is that openvpn is using openssl-3.x when it is opening the .p12 file to access the contents.

However I have identified that the option for the openvpn configuration file of using

providers legacy default

is also available in the openvpn-2.5.x series. I had originally thought it was only in openvpn-2.6.x

I added that option line manually to the n2n conf file at the client end and this allowed the n2n connection to successfully connect.

The option is not needed at the server end as there, individual .pem files are specified for the ca, servercert and serverkey while at the client end the combined .p12 file is used.

I believe this will only be an issue for existing n2n clients and that new n2n connections made with openssl-3.x will work properly. I will check this out to confirm.
If that is correct then the fix for this basically has to be some code in the update.sh script to add in the providers legacy default line to any existing n2n client connections.

I will also have to look at the restore function of the IPFire backup to do an openssl check on any n2n .p12 certificates that get restored to see if they need to have the providers legacy default line added to the configuration file.

This might take me a day or two to figure out and test but I will try and do it as quickly as feasible.
Comment 2 Adolf Belka 2023-05-31 18:49:05 UTC

Your suggestion in the email about making a modification in the openssl configuration file is a good idea.

I will give that a try on my n2n vm setup.

I will also try re-uploading the client package from the n2n server to the n2n client and see if that then works without needing the "providers legacy default" line added.
Comment 3 Adolf Belka 2023-05-31 20:17:18 UTC
Putting the legacy provider into the openssl.cnf file allowed the downloading of the previously created insecure .p12 file without needing the -legacy option in the openssl commands for extracting the certificate and the key.

However it made no difference to the n2n client connection. This still failed when the "providers legacy default" option line was removed from the n2n conf file.

This looks like the use of openssl has been built into the openvpn binary and is not using the openssl.cnf file or is ignoring the legacy portion of it if it exists.

As we already have the -legacy option in the ovpnmain.cgi openssl commands that need to use it for accessing or extracting the contents from .p12 files then it seems best to leave those as they are and not add in the extra legacy lines into the openssl.cnf file

I will focus on how to get the "providers legacy default" line into the n2n conf file.
Comment 4 Adolf Belka 2023-05-31 21:32:42 UTC
I have been able to modify ovpnmain.cgi so that if the n2n client connection is deleted and re uploaded then the line "providers legacy default" is added to the end of the n2nconf file.

It should be possible to search all the n2n config files in /var/ipfire/ovpn/n2nconf/ and if they have the word client in the first line then to add "providers legacy default" at the end of those files using the update.sh script.
Comment 5 Adolf Belka 2023-06-01 12:06:11 UTC
I have found some additional locations in the ovpnmain.cgi perl code where I make it add the line "providers legacy default" to the n2n configuration file.

This now means that when an existing client package is re-uploaded it will have that line added but also for an existing client package without that line that was unable to connect, just selecting the edit pencil option and saving without changing anything results in the n2n configuration file having the line included and being able to connect successfully again.

So at the worst people having a problem connecting with an existing n2n configuration just need to go to the client end, select the edit icon for each connection and then save and they should all be able to connect.

This should be a reasonable approach for dealing with any restores from a CU before 175. It just needs to be written into the wiki which I will do when CU175 is released.

I will now look at some code to be able to add to the update.sh script to try and update all existing client configs to have that line included without any manual intervention by the users.
Comment 6 Adolf Belka 2023-06-04 19:00:47 UTC
Patch to fix this bug plus a patch adding code to the Core Update update.sh script to find all n2n config files and add "providers legacy default" if it is not yet present.

Successfully tested out on my vm testbed running with a n2n openvpn tunnel bbetween two vm IPFire systems.

Comment 7 Adolf Belka 2023-06-05 11:58:39 UTC
Additional patch created and submitted which will add the line "providers legacy default" to the OpenVPN N2N Client configs during restore if it is not already present.

Comment 9 Adolf Belka 2023-06-12 18:34:41 UTC
Additional commit merged to correct incorrect return values on iscertlegacy subroutine.

Comment 10 Adolf Belka 2023-06-12 18:36:18 UTC
Modified patch that only uses the legacy options for certificates that are legacy based.

Comment 11 Adolf Belka 2023-06-12 18:36:44 UTC
Verified on CU175 Testing
Comment 12 Adolf Belka 2023-06-12 18:37:43 UTC
CU175 released.


Confirmed working after return code corrected (comment 9)