Hello Adolf, hello Michael,
thank you very much for verifying the OpenVPN functionality for PKCS12 containers imported from IPFire systems running OpenSSL 1.1.1x.
As discussed yesterday, I tested the same functionality for IPsec, both for N2N and roadwarrior connections. For both cases, an IPFire installtion running Core-Update 175 Development Build master/3d2beee7 was able to import PKCS12 containers created on an IPFire installation running Core Update 174 without any error message whatsoever, and the IPsec connections could be established afterwards.
As far as I am aware, all blocking issues with Core Update 175 are now resolved, and this update can finally be released! @Michael, a draft for its release announcement should be with you already.
To echo Erik, many many thanks for all the hard work, and dealing with the massive headache the transition to OpenSSL 3.x has induced!
All the best, Peter Müller
True, thanks to all for this.
Best,
Erik
Am Dienstag, dem 06.06.2023 um 17:23 +0200 schrieb Adolf Belka:
Hi Michael,
I tested out a newly created openvpn connection on Openssl-3.x and installed that on my laptop with the existing legacy providers lines in the openssl.cnf file commented out. that connection was successfully made.
So what we discussed is the case. Any new connection from CU175 onwards will work with a system with OpenSSL-3.x
It was what we hoped for and expected but it is good to have it confirmed.
Regards,
Adolf.
On 06/06/2023 11:33, Michael Tremer wrote:
Thank you.
I just created a page to explain this problem:
https://wiki.ipfire.org/configuration/services/openvpn/openssl-3-transition
Please feel free to edit if I forgot to mention something.
We should include this in the change log for the release, but highlight that this breaking change has not been introduced in c175, but c175 has the fix.
-Michael
On 4 Jun 2023, at 20:14, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
I Have submitted a patch set for fixing the bug#13137 related to OpenVPN. This patch set together with the one for bug#13138 related to IPSec that I shipped yesterday fix the major bugs I found for CU175.
Sorry it took a bit longer than I had hoped for.
Please let me know if there are any problems with what I have produced and I will work to sort them out.
I am not aware of any other blocking bugs for CU175 at this point in time. :crossed_fingers:
Regards,
Adolf.
On 02/06/2023 21:35, Adolf Belka wrote:
The poster found the following reference
https://serverfault.com/questions/857131/odd-error-while-using-openssl
which suggests that openssl can sometimes give spurious error messages if unique_subject is not explicitly defined as yes but it doesn't give any suggestion for why this would have occurred with the move to openssl-3.x
Regards,
Adolf.
On 02/06/2023 21:28, Adolf Belka wrote:
Hi All,
On 02/06/2023 19:54, Adolf Belka wrote: > Hi All, > > Just when you thought it was safe to get back in the water > - aaaaah. > > > I suspected that IPSec would also suffer from the same > problem of openssl-3.x vs openssl-1.1.1x for the opening of > .p12 certificates. > > Today, from feedback from Roberto Pena in the forum, it > turns out that trying to create a Root/Host certificate set > for IPSec causes an error message to be created. > > I reproduced this on CU175 Testing build master/9797af30 > and confirmed that it did not happen in CU174. > > > I added the -legacy option into every openssl command in > vpnmain.cgi dealing with .p12 files but this did not solve > this problem. I then added -legacy to every openssl > command. This solved the problem. > Someone else in that thread about the IPSec Root/Host certificate creation has suggested adding
"unique_subject = yes"
into /var/ipfire/certs/index.txt.attr
have tried that and it does solve the problem.
However now have the dilemma of which solution to use, the unique_subject or the legacy option in the openssl commands.
I have asked the person who suggested the unique_subject fix, why this is the correct fix to this problem. I searched on the internet but only found comments that the default value of that variable is yes anyway and no reference to it needing to be changed because of a changed from openssl-1.1.1x to openssl-3.x
I will see what input the poster provides but does anyone on this mailing list have any suggestion as to how the unique_subject = yes fix works and why it is needed with openssl-3.x or any input on how to make the decision between the two approaches or if both should be used?
Regards,
Adolf.
> > I then tried only adding the legacy option to each non .p12 > openssl command one at a time but this also did not fix the > problem. So more than one of the non .p12 commands needs to > be defined as legacy at the same time. > > I thought if every openssl command was going to have the > legacy option then the same effect should be possible by > adding the legacy provider into the openssl.cnf file. Tried > this but it didn't solve the error message when creating > the Root/Host IPSec certificate set. So there must be some > sort of difference between the command line legacy option > and the legacy provider option in the openssl.cnf file. > > > So I will also submit a patch set for the vpnmain.cgi file > where all openssl commands have the legacy option added. > > > The same will be done for the ovpnmain.cgi file to be on > the safe side. Currently I had only added it to the openssl > commands running on .p12 files. > > I did test creating the Root/Host certificate set on > OpenVPN with openssl-3.x and that worked successfully but I > think having the legacy option on every openssl command > should not cause anything to break. > > > Hope to provide a patch set for the various IPSec/OpenVPN > openssl issues found over the weekend, presuming no one > finds any further issues. As Michael has said in the past. > Better to get any patch fix correct than to have a faulty > one quickly. > > > Regards, > > Adolf. > > > On 31/05/2023 20:53, Adolf Belka wrote: >> Hi Michael, >> >> On 31/05/2023 20:43, Michael Tremer wrote: >>> Hello, >>> >>> Does this mean that OpenVPN cannot read those files >>> either? I had that suspicion. >> I believe that is the case. The failure I found has no >> openssl command in the cgi file and adding "providers >> legacy default" to the end of the client n2n conf file >> made everything work again. >> >> Your idea of making a modification to the openssl conf >> file is a good one and I will try that out and see if >> that works. If so then that would be the better approach >> as then any certificates would be covered by the legacy >> approach if required. >> >> Regards, >> Adolf. >>> >>> I will halt the update for now and let’s take some more >>> time to figure this one out. >>> >>> Best, >>> -Michael >>> >>>> On 31 May 2023, at 19:42, Adolf Belka >>>> adolf.belka@ipfire.org wrote: >>>> >>>> Hi All, >>>> >>>> I have figured out how to solve the problem. I have >>>> to add "providers legacy default" into the n2n client >>>> configuration file. >>>> >>>> I have raised a bug on this >>>> https://bugzilla.ipfire.org/show_bug.cgi?id=13137%C2%A0and >>>> will submit a patch as soon as feasible. >>>> >>>> Regards, >>>> >>>> Adolf. >>>> >>>> >>>> On 31/05/2023 17:07, Adolf Belka wrote: >>>>> Hi All, >>>>> >>>>> I have a blocking bug. >>>>> >>>>> On 29/05/2023 23:34, Adolf Belka wrote: >>>>>> >>>>>> >>>>>> On 26/05/2023 16:28, Michael Tremer wrote: >>>>>>> Thank you very much for letting me know. I >>>>>>> wasn’t aware at all. >>>>>>> >>>>>>> I reverted those changes in next and if the >>>>>>> build goes through I will merge the branch back >>>>>>> into master again. >>>>>> >>>>>> Just as a reminder the reversion changes went >>>>>> through on next but are not yet reverted in >>>>>> master. This needs to be done before CU175 is >>>>>> released otherwise n2n connections will fail to >>>>>> work properly. >>>>>> >>>>> The reversions have been applied to master (Core >>>>> Update 175) and I did an update but have found that >>>>> the n2n connection when the end that had the client >>>>> upload has stopped working. This is definitely not >>>>> because of bug#11048 as all of that has been >>>>> reverted (confirmed by looking at the ovpnmain.cgi >>>>> file) >>>>> >>>>> I have realised that what is happening is the same >>>>> as for the insecure roadwarrior certificate that >>>>> was created with openssl-1.1.1x would not work with >>>>> openssl-3.x. I fixed that with the addition of the >>>>> legacy option into the openssl command for that >>>>> client package download. >>>>> >>>>> The same thing is happening with the n2n >>>>> connection. I will find the command that access the >>>>> .p12 file in the zip package and add the legacy >>>>> option to that. Presuming it works I will raise and >>>>> submit a patch to fix it. >>>>> >>>>> I will also raise a bug for it and assign myself to >>>>> it. >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> >>>>>> Regards, >>>>>> Adolf. >>>>>> >>>>>>> >>>>>>> -Michael >>>>>>> >>>>>>>> On 26 May 2023, at 14:33, Adolf Belka >>>>>>>> adolf.belka@ipfire.org wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 24/05/2023 11:02, Michael Tremer wrote: >>>>>>>>> Hello, >>>>>>>>>> On 24 May 2023, at 09:47, Adolf Belka >>>>>>>>>> adolf.belka@ipfire.org wrote: >>>>>>>>>> >>>>>>>>>> Hi Michael, >>>>>>>>>> >>>>>>>>>> On 24/05/2023 10:07, Michael Tremer >>>>>>>>>> wrote: >>>>>>>>>>> It looks like we might not want to >>>>>>>>>>> release the forthcoming Core Update >>>>>>>>>>> before this. >>>>>>>>>>> >>>>>>>>>>> I did not hear any rumours about what >>>>>>>>>>> might be the issue, but I would say >>>>>>>>>>> that it wouldn’t hurt us to wait. >>>>>>>>>>> >>>>>>>>>>> What other outstanding issues do we >>>>>>>>>>> have that are currently blocking the >>>>>>>>>>> update? >>>>>>>>>>> >>>>>>>>>> The fix for Bug#13117 has been merged >>>>>>>>>> into master so that is no longer >>>>>>>>>> blocking. >>>>>>>>>> >>>>>>>>>> As mentioned to Peter, I recommend >>>>>>>>>> reverting my fix for Bug#11048 as some >>>>>>>>>> issues were found by myself (missed in my >>>>>>>>>> own testing) plus from other testers >>>>>>>>>> reporting in the forum. I am making >>>>>>>>>> progress on this but there are still some >>>>>>>>>> bits outstanding. The bug has been around >>>>>>>>>> for a long time so it won't hurt for it >>>>>>>>>> to wait till Core Update 176. >>>>>>>>> Okay. Let’s rather have the right fix than >>>>>>>>> a quick one. I agree! >>>>>>>> The reversion of the update.sh script was >>>>>>>> done two days ago but there are 4 other >>>>>>>> commits for the same bug fix that also need >>>>>>>> to be reverted. >>>>>>>> >>>>>>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=762c88ec4d85e3a4f7265b88... >>>>>>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=82822934ba769bca4235cd2a... >>>>>>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=070abb0d011ff71e5aefd170... >>>>>>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=18bece0edbd817933f48fdbf... >>>>>>>> >>>>>>>> just to make sure that those don't get >>>>>>>> missed. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Adolf. >>>>>>>>>> I haven't found anything else that was a >>>>>>>>>> problem and I haven't seen any other >>>>>>>>>> issues mentioned in the forum that look >>>>>>>>>> to be caused by CU175. >>>>>>>>> That sounds good then! >>>>>>>>>> Regards, >>>>>>>>>> Adolf. >>>>>>>>>>> -Michael >>>>>>>>>>> >>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>> >>>>>>>>>>>> From: Tomas Mraz tomas@openssl.org >>>>>>>>>>>> Subject: Forthcoming OpenSSL Releases >>>>>>>>>>>> Date: 24 May 2023 at 05:06:12 BST >>>>>>>>>>>> To: "openssl-project@openssl.org" >>>>>>>>>>>> openssl-project@openssl.org, >>>>>>>>>>>> "openssl-users@openssl.org" >>>>>>>>>>>> openssl-users@openssl.org, >>>>>>>>>>>> openssl-announce@openssl.org >>>>>>>>>>>> Reply-To: openssl-users@openssl.org >>>>>>>>>>>> >>>>>>>>>>>> The OpenSSL project team would like >>>>>>>>>>>> to announce the forthcoming release >>>>>>>>>>>> of OpenSSL versions 3.0.9, 1.1.1u and >>>>>>>>>>>> 1.0.2zh. Note that OpenSSL 1.0.2 >>>>>>>>>>>> is End Of Life and so 1.0.2zh will be >>>>>>>>>>>> available to premium support >>>>>>>>>>>> customers only. >>>>>>>>>>>> >>>>>>>>>>>> These releases will be made available >>>>>>>>>>>> on Tuesday 30th May 2023 >>>>>>>>>>>> between 1300-1700 UTC. >>>>>>>>>>>> >>>>>>>>>>>> These are security-fix releases. The >>>>>>>>>>>> highest severity issue fixed in >>>>>>>>>>>> each of these three releases is >>>>>>>>>>>> Moderate: >>>>>>>>>>>> >>>>>>>>>>>> https://www.openssl.org/policies/secpolicy.html >>>>>>>>>>>> >>>>>>>>>>>> Yours >>>>>>>>>>>> The OpenSSL Project Team >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Sent from my laptop >>>>>>> >>>>>>> >>>