Openvpn fails to generate server certificate

Virtual Private Networks OpenVPN
1

Dear all,

I’m on a freshly installed IPFire instance updated from core 182 to 183

IPFire version IPFire 2.29 (aarch64) - core183
Pakfire version 2.29-aarch64
Kernel version Linux guard.aheinzel.local 6.6.15-ipfire #1 SMP PREEMPT_DYNAMIC Fri Feb 9 18:47:53 GMT 2024 aarch64 GNU/Linux

openssl version: OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30 Jan 2024)

When attempting to setup openvpn the server certificate can’t be generated (services → openvpn → generate root/host certificates → generate root/host certificates). DH and the CA are created successfully, it is only the server certificate that fails. In the upper left corner of the generate root/host certificates page an error message that openssl exited with 256 is shown. In the log file the following error message is found:

A challenge password :An optional company name :Error adding request extensions from section server
20108990FFFF0000:error:04000067:object identifier routines:OBJ_txt2obj:unknown object name:crypto/objects/obj_dat.c:426:
20108990FFFF0000:error:04000067:object identifier routines:OBJ_txt2obj:unknown object name:crypto/objects/obj_dat.c:426:
20108990FFFF0000:error:11000079:X509 V3 routines:v2i_AUTHORITY_KEYID:no issuer certificate:crypto/x509/v3_akid.c:156:
20108990FFFF0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:crypto/x509/v3_conf.c:48:section=server, name=authorityKeyIdentifier, value=keyid,issuer:always

The error appears to be due to the presence of AKID in the server extensions section (see recent discussion in openssl on github)

As a crude workaround I have for now removed the AKID extension by duplicating the config while generating the certificate request and this allowed for successful generation of the server certificate via the IPFire web GUI.

diff ovpnmain.cgi ovpnmain.cgi.bak
1866,1870d1865
<             open(REQCNF, ">", "${General::swroot}/ovpn/openssl/ovpn.cnf.req");
<             my $lines = `cat "${General::swroot}/ovpn/openssl/ovpn.cnf"`;
<             $lines =~ s/authorityKeyIdentifier.*//g;
<             print REQCNF $lines;
<             close(REQCNF);
1876c1871
<                       '-config', "${General::swroot}/ovpn/openssl/ovpn.cnf.req" )) {
---
>                       '-config', "${General::swroot}/ovpn/openssl/ovpn.cnf" )) {
2 Likes
2

Hallo @aheinzel

Welcome to the IPFire community.

I have confirmed the result that you found.

This has come in with a bug fix in openssl-3.2.x

According to that openssl issue link you provided the CSR should not have the SKID and AKID present but due to a previous bug they were ignored. Now with the bug fixed in openssl the presence of the AKID causes the failure.

Thanks very much for finding this and reporting it.

Could you please raise a bug for this and I will have a look at how to deal with it.

https://www.ipfire.org/docs/devel/bugzilla

Your IPFire community login email address and password will act as your login credentials for the IPFire Bugzilla.

When there is an OpenSSL version change I always test out the OpenVPN RW and N2N processes with existing connections and with creating new ones.
From now on I will also test out the generation of a new X509 set.

4

Hello @bonnietwin,

thank you for the warm welcome to the community forum.

I raised a new bug report in bugzilla as you suggested. Thank you for your efforts maintaining IPFire.

5

Hello @bonnietwin,

Sorry for the confusion - I have another message from you in my inbox that for some reason is not visible here in the community forum. In consequence this message may appear a bit out of context…

Yes you are right I just removed all authorityKeyIdentifier entries from the temporary config as I then only use the temporary config while generating the certificate request but not for the subsequent issuing of the certificate itself (here the original config is used again). I need to double check but I think it would even be possible to drop the extensions argument from openssl req invocation?

6

It is me causing the confusion. Sorry.

I wrote a reply which, after thinking about it, had several errors in it on my part so in the end I deleted my post but you had already received the notification.

The section you modified in the ovpnmain.cgi uses the [ server ] section of the ovpn.cnf for the extensions input into the csr generation.
Changing that section to remove the AKID and SKID allowed the host certificate to be created.

However the [ server ] section is also used in the next openssl command in ovpnmain.cgi for the signing of the CSR by the CA. That works if the AKID/SKID are present or not, in terms of creating the root/host certificate.

What I don’t know yet is if the signing of the CSR by the CA does not have the AKID/SKID specified does this cause some other problem later on when creating the client connection certificates or doing a revocation action.

I will try out both approaches in my testing to be certain

That is great. Thanks very much. I can then enter all my investigation info and the patches I submit and the other devs can also then review and modify anything I do in case it has errors in it.

If you find anything further yourself in your investigation feel free to add the info into the bug report.

7

Hi @all,
I just wanted to ask if there is a fix for this yet?
I’d rather not change anything in cgi files I hardly understand.

TIA
VT

8

Hallo @viennatux

Welcome to the IPFire community.

The fix is in the git repo for what will become Core Update 185.

Core Update 184 was already well into Testing phase when the patch update was available.

9

Hi Adolf, thanks for the speedy reply.
Is there a timeframe for the update?
TIA

10

Not a firm one. I would expect Core Update 184 to get its full release pretty soon, maybe by end of this week.

Then CU185 would probably go to Testing release by maybe end of next week. How long it will be in Testing phase depends if any issues are found and how long it takes to fix them.

The above is my best guess but it could also take longer.

The alternative that you have is to take a backup of your current system and download it to a separate machine. Then do a Fresh Install of Core Update 182 and restore the backup.

Then you could create the new root/host certificates. Then do the Core Update to 183. The bug in Core Update 183 is to create the root/host certificates from fresh. Any existing ones that are brought in from Core Update 182 or earlier will work fine.

11

Thanks, but unfortunately I only downloaded the 183 iso and didn’t find an older image to download.
Any suggestions or links?
TIA

12

Here is a link for the CU182 downloads

https://www.ipfire.org/downloads/ipfire-2.27-core182

13

Thank you.