Thanks for reporting this bug. The c_rehash script has indeed had changes made in two recent OpenSSL 1.1.1 versions:
* c_rehash was changed between 1.1.1n and 1.1.1o to address CVE-2022-1292 [1]
* c_rehash was changed again between 1.1.1o and 1.1.1p to address CVE-2022-2068 [2]
Changes to c_rehash for 1.1.1o were insufficient to fully address the issue of shell metacharacters not being properly sanitised per CVE-2022-1292. So more significant changes were made to c_rehash in 1.1.1p to cover all possibilities per CVE-2022-2068.
The changes in 1.1.1p required reworking of a Debian patch (c_rehash-compat.patch) that modifies c_rehash to always create old hashes for compatibility. This Debian patch was created back in 2010 and has persisted in all Debian OpenSSL versions through 1.1.1n-0+deb11u3 (backport of 1.1.1n to Debian stable, which is currently Bullseye).
A lack of Perl programming experience on my part combined with me not ever having used or tested c_rehash myself resulted in my initial rework of c_rehash-compat.patch for OpenSSL 1.1.1p (carried over to 1.1.1q) being incorrect for the new code changes. As confirmed by your bug report.
Doing some investigation this morning relative to this issue has revealed the simple error that I made. It was a missing parameter when calling the new link_hash subroutine, which was added in 1.1.1p and is now called by the link_hash_cert and link_hash_crl subroutines (these were essentially merged, due being mostly common code, into the new link_hash subroutine).
Adding the missing parameter for the new link_hash subroutine calls and bumping the position of the -subject_hash or -subject_hash_old (the one added by the Debian patch) parameter fixes the issue. A corrected version of c_rehash on my own system now works as expected.
Updated OpenSSL 1.1.1q packages will be uploaded to ppa:savoury1/encryption shortly, and once built and published the revised packages will then be copied to all other SavOS PPAs (ppa:savoury1/*) where this version of OpenSSL is also published (including ppa:savoury1/{ffmpeg4,graphics,multimedia} as on your affected server).
Also note that upstream do now recommend using rehash, which you did to resolve the issues you were having, rather than c_rehash that is described as obsolete by upstream. This detail is mentioned in the notes linked below.
Thanks for reporting this bug. The c_rehash script has indeed had changes made in two recent OpenSSL 1.1.1 versions:
* c_rehash was changed between 1.1.1n and 1.1.1o to address CVE-2022-1292 [1]
* c_rehash was changed again between 1.1.1o and 1.1.1p to address CVE-2022-2068 [2]
Changes to c_rehash for 1.1.1o were insufficient to fully address the issue of shell metacharacters not being properly sanitised per CVE-2022-1292. So more significant changes were made to c_rehash in 1.1.1p to cover all possibilities per CVE-2022-2068.
The changes in 1.1.1p required reworking of a Debian patch (c_rehash- compat. patch) that modifies c_rehash to always create old hashes for compatibility. This Debian patch was created back in 2010 and has persisted in all Debian OpenSSL versions through 1.1.1n-0+deb11u3 (backport of 1.1.1n to Debian stable, which is currently Bullseye).
A lack of Perl programming experience on my part combined with me not ever having used or tested c_rehash myself resulted in my initial rework of c_rehash- compat. patch for OpenSSL 1.1.1p (carried over to 1.1.1q) being incorrect for the new code changes. As confirmed by your bug report.
Doing some investigation this morning relative to this issue has revealed the simple error that I made. It was a missing parameter when calling the new link_hash subroutine, which was added in 1.1.1p and is now called by the link_hash_cert and link_hash_crl subroutines (these were essentially merged, due being mostly common code, into the new link_hash subroutine).
Adding the missing parameter for the new link_hash subroutine calls and bumping the position of the -subject_hash or -subject_hash_old (the one added by the Debian patch) parameter fixes the issue. A corrected version of c_rehash on my own system now works as expected.
Updated OpenSSL 1.1.1q packages will be uploaded to ppa:savoury1/ encryption shortly, and once built and published the revised packages will then be copied to all other SavOS PPAs (ppa:savoury1/*) where this version of OpenSSL is also published (including ppa:savoury1/ {ffmpeg4, graphics, multimedia} as on your affected server).
Also note that upstream do now recommend using rehash, which you did to resolve the issues you were having, rather than c_rehash that is described as obsolete by upstream. This detail is mentioned in the notes linked below.
[1] https:/ /www.openssl. org/news/ secadv/ 20220503. txt /www.openssl. org/news/ secadv/ 20220621. txt
[2] https:/