Bug 13808 - vpnmain.cgi provides client certs with the sha1 hash instead of the sha256 hash
Summary: vpnmain.cgi provides client certs with the sha1 hash instead of the sha256 hash
Status: ASSIGNED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: - Unknown - - Unknown -
Assignee: Adolf Belka
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-01-14 19:30 UTC by Adolf Belka
Modified: 2025-01-14 19:38 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Adolf Belka 2025-01-14 19:30:55 UTC 
In June 2023 ovpnmain.cgi was updated to take into account the move to Openssl-3.x by the addition of the -legacy option into the openssl commands.

The same action was taken by myself with vpnmain.cgi.

Subsequently an update was made to ovpnmain.cgi that only added the -legacy option if the certificate that had been created was a legacy version.

This update was not subsequently put into vpnmain.cgi, so all certificates produced are legacy ones, even if the root/host certificates for the ipsec page have been created with openssl-3.x
Comment 1 Adolf Belka 2025-01-14 19:37:39 UTC 
I have done a test of removing the -legacy option from line 2218 in vpnmain.cgi

Creating a new client certificate then ended up with a non legacy version that had the MAC: sha256 message in it indicating that it was not legacy based.

I will go though the vpnmain.cgi and modify all appropriate entries to only use -legacy if the involved .p12 file was legacy based. This should only happen if users are still using a root/host x509 certificate set that was created before openssl-3.x was installed, or from a restore from an old backup or from an uploaded root/host certificate set that was created with openssl-1.x