Hello,
On 31 May 2023, at 19:53, Adolf Belka adolf.belka@ipfire.org 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.
Hmm, but does the OpenVPN daemon read it? We must configure it somewhere then.
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.
I kind of like it too, but I am not sure whether this is more practical than adding -legacy because the CGI file is calling openssl many times without the -config argument. So we would need to add that instead.
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 and 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