On CentOS Stream 9:

Downgraded openssl:
openssl-3.0.1-5.el9.x86_64.rpm
openssl-libs-3.0.1-5.el9.x86_64.rpm

# rpm --checksig -v https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/03580141-ovirt-release-master/ovirt-release-master-4.5.0-0.0.master.20220228074945.git0f867a9.el9.noarch.rpm
https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/03580141-ovirt-release-master/ovirt-release-master-4.5.0-0.0.master.20220228074945.git0f867a9.el9.noarch.rpm:
    Header V3 RSA/SHA1 Signature, key ID 40991906: OK
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    V3 RSA/SHA1 Signature, key ID 40991906: OK
    MD5 digest: OK

upgraded again:
openssl-3.0.1-12.el9.x86_64.rpm
openssl-libs-3.0.1-12.el9.x86_64.rpm

rpm --checksig -v https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/03580141-ovirt-release-master/ovirt-release-master-4.5.0-0.0.master.20220228074945.git0f867a9.el9.noarch.rpm
https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/03580141-ovirt-release-master/ovirt-release-master-4.5.0-0.0.master.20220228074945.git0f867a9.el9.noarch.rpm:
    Header V3 RSA/SHA1 Signature, key ID 40991906: BAD
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    V3 RSA/SHA1 Signature, key ID 40991906: BAD
    MD5 digest: OK


So it seems to be openssl issue

Seems to be caused by:
* Tue Feb 22 2022 Clemens Lang <cllang> - 1:3.0.1-8
- Disable SHA1 signature creation and verification by default
- Set rh-allow-sha1-signatures = yes to re-enable
- Resolves: rhbz#2031742

> Header V3 RSA/SHA1 Signature, key ID 40991906: BAD
> V3 RSA/SHA1 Signature, key ID 40991906: BAD

These signatures are no longer considered secure. Which key was used to create this signature and what tooling? The tooling should be updated to switch to a modern hash algorithm that is not considered insecure.

Disabling SHA1-based signatures is likely to affect any number of 3rd party/vendor packages over which neither us or the customers have any control. Many users ran into similar issues with RHEL 8 FIPS-mode already due to vendor provided rpm's being built and signed with ancient toolchains, and were forced to either use --nosignature or repackage said material with modern tools to get around it when vendors were unresponsive.

As the change was accompanied by an option to re-enable it on per-system basis I don't see any problem here, the change and the workaround just need sufficient documentation.

For the record, here are the signatures on that package:

$> rpm -q --qf '%{SIGPGP:armor}' ovirt-release-master-4.5.0-0.0.master.20220228074945.git0f867a9.el9.noarch.rpm
-----BEGIN PGP SIGNATURE-----
Version: rpm-4.17.0 (NSS-3)

iQEVAwUAYhx/NVfI5DlAmRkGAQJPhAgAvQg9K072O5qINX84rfo2UegCEIwHhZX8
JjY7qs77TG2kffl2uDgm2T9QjVldb0U7QkXWzE4hhM2t250md/V6Bcsz/97w06Nm
kaBh+e5H1Ny4B4SHlO8PdOlyRjKBqldh8TDxFMw3gMSbkZXOcRnXCaaRqsZ9LQ5A
2RJy2MHF0lWwegTlLq/Fhe3jN4DEO2Ax0AF6jGtDDOOzGOM5WfUxDmQYAelGGXF0
T17n40bav+aaraWVdRD0tR9+VC9eXh4raG/rXGqkmubrdTfopzHNN3IQ4A5vu0W+
je29ux8jR0frGEwQqGcK1xS4FtLWKwckcORrt0HmuDuw8vr3BB0o8w==
=6oow
-----END PGP SIGNATURE-----
$> rpm -q --qf '%{RSAHEADER:armor}' ovirt-release-master-4.5.0-0.0.master.20220228074945.git0f867a9.el9.noarch.rpm
-----BEGIN PGP SIGNATURE-----
Version: rpm-4.17.0 (NSS-3)

iQEVAwUAYhx/NVfI5DlAmRkGAQIZswgAnjPzh7eAUvBYI/yrSMVR69ykw+yBIx7O
okIZobu5lPZdZSKKpzHQXFQax9UvcBli4tEIJGcOBxB6xrlEfAT3bW2LGSCSwRug
DamWGyU6WqQ/ggxzrhHzhxgZGz4OyAQL43E9bllSFF3s+XlKw2Lx5HQ2kp5LEixo
JRkieUI/s+IZxkr0C/7BYKdL2utS96XtTM1AHStXmHTj/6T9Udc6EJcVNd4g7vEZ
oOEYKG31Gskx3zXxRe+NKRedadCytJZeq3u3GJF+/IlSERvQyR3cqQjT2AhoS1wL
MFCGBuiLyblmVEOk7glDmSp6+mmjTI7ziQJqEc4Be5c1WC6XAHdnJw==
=4RSV
-----END PGP SIGNATURE-----


Pipe those to pgpdump to see the use of SHA1:

$> rpm -q --qf '%{SIGPGP:armor}' ovirt-release-master-4.5.0-0.0.master.20220228074945.git0f867a9.el9.noarch.rpm | pgpdump
Old: Signature Packet(tag 2)(277 bytes)
        Ver 3 - old
        Hash material(5 bytes):
                Sig type - Signature of a binary document(0x00).
                Creation time - Mon Feb 28 08:52:21 CET 2022
        Key ID - 0x57C8E43940991906
        Pub alg - RSA Encrypt or Sign(pub 1)
        Hash alg - SHA1(hash 2)
        Hash left 2 bytes - 4f 84
        RSA m^d mod n(2048 bits) - ...
                -> PKCS-1

$> rpm -q --qf '%{RSAHEADER:armor}' ovirt-release-master-4.5.0-0.0.master.20220228074945.git0f867a9.el9.noarch.rpm | pgpdump
Old: Signature Packet(tag 2)(277 bytes)
        Ver 3 - old
        Hash material(5 bytes):
                Sig type - Signature of a binary document(0x00).
                Creation time - Mon Feb 28 08:52:21 CET 2022
        Key ID - 0x57C8E43940991906
        Pub alg - RSA Encrypt or Sign(pub 1)
        Hash alg - SHA1(hash 2)
        Hash left 2 bytes - 19 b3
        RSA m^d mod n(2048 bits) - ...
                -> PKCS-1

This specific file seems to have been signed by fedora COPR using /bin/sign, see https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/03580141-ovirt-release-master/backend.log.gz.

It seems /bin/sign may originate from the obs-sign package. There seem to be a few ways to get its sign utility to create SHA-256 hashes:
 - the self-signature of the GPG key used for the signature is SHA256, SHA224, SHA384, or SHA512
 - a config file sets the "hash" key to "sha256"
 - the command line specifies -h sha256

The default is SHA1. Given that the default will soon no longer be useful, maybe we should switch the default. I'm CC'ing Miroslav Suchy <msuchy>, who maintains the obs-signd package in fedora: https://src.fedoraproject.org/rpms/obs-signd.

FYI obs-sign supports SHA256. It just defaults to SHA1 
   https://github.com/openSUSE/obs-sign/blob/master/sign.c#L50
I opened an issue about changing the default
  https://github.com/openSUSE/obs-sign/issues/34
We can start using SHA256 in Copr using `sign -h sha256` 
  https://pagure.io/copr/copr/issue/2106

I agree with Panu in comment #5 that this need just propper documentation. Maybe even a check in in-place upgrade tool. As it may surprise lots of customers in the middle of upgrade.

No change in RHEL is needed. The change in Copr and obs-sign is out of scope of RHEL.

This is a system-wide policy change in openssl so any explaining (aka documentation) belongs there. 
This will certainly require a release note mention, including one on rpm which is one of the affected users.

*** Bug 2059424 has been marked as a duplicate of this bug. ***

For those who tries to figure out how to workaround:

dnf upgrade -y \
 https://kojihub.stream.centos.org/kojifiles/packages/crypto-policies/20220223/1.git5203b41.el9/noarch/crypto-policies-20220223-1.git5203b41.el9.noarch.rpm \
 https://kojihub.stream.centos.org/kojifiles/packages/crypto-policies/20220223/1.git5203b41.el9/noarch/crypto-policies-scripts-20220223-1.git5203b41.el9.noarch.rpm

as the needed crypto-policies didn't land on mirrors yet, then:

update-crypto-policies --set LEGACY

solves.

openssl already will track documentation part under bug 2031742.
I suggest (and I done it) to convert this to leapp bug under RHEL 8.
Leapp should create an actor which will check whether repositories (can be 3rd party) used for upgrade are using rpm signatures with SHA1 checksum. And in such a case warn the user before the in-place upgrade.

Only thing we can do here is to provide good report / error msg to users with hint what to do:
 * remove any problematic packages prior the upgrade / contact vendors for new builds of packages
   with good signature
 * apply the LEGACY system wide crypto policies

The upstream PR:
  https://github.com/oamg/leapp-repository/pull/854

The PR has been merged.

(In reply to Petr Stodulka from comment #26)
> The PR has been merged.

Was there a new version of leapp released meanwhile ?

Yes, and new version of leapp-repository as well. The fix is already part of the leapp-repository-0.16.0-1.el8_6 build. As this is the first build that is going to be released in RHEL 8, closing as upstream.

For more information track: https://bugzilla.redhat.com/show_bug.cgi?id=1997076