Description of problem:

The main issue is well explained in  https://issues.redhat.com/browse/SAT-29322 and https://issues.redhat.com/browse/SAT-30186 . 

Signatures using the SHA-1 hash algorithm have been disabled by default in Red Hat Enterprise Linux 9. Probably due to the same, it was decided to make sure that Satellite is also not using any certs with SHA-1 Signatures. 

Two checks were developed via the said JIRAs and backported in katello-certs-check ( installer ) and foreman-maintain of Satellite 6.16.2 , preventing the upgrade or installation of Satellite 6.16.2+ , if the presence of SHA1 signature has been detected in the CA certificate used by satellite. 

The solution is to reach back to the CA authority and collect a new set of CA certs with a more secure signature algorithm e.g. SHA256 or later. 

But not every end-user can do so. Neither the users nor their CA provider can easily replace the certs ( probably, as they are already being used organization-wide ) and for them, neither a new installation nor upgrade to 6.16.2 or later is possible, because of the sha1-checks in place.

How reproducible:

Is this issue a regression from an earlier version:

Steps to Reproduce:

1.

2.

3.

Actual behavior:

As explained in the description

Expected behavior:

A) Figure out a way to allow Satellite 6.16 to use SHA1. We even document certain approaches for RHEL 10 in https://access.redhat.com/solutions/7105593 but not sure if we can fix the installer in a way that, It can use the curl and openssl binary provided by OS itself, but not puppet-agent. 

B) Or, provide enough technical justification to the end-users explaining the reason behind this decision taken to not support SHA1 anymore and what alternatives they have here. 

Business Impact / Additional info:

End-users with no control over their CA, cannot upgrade their satellite or install a new version of a satellite