The installer should check that the cert rpms installed on the system are corresponding to those present in ~/ssl-build (or in the capsule certs tar.gz)
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1218251
Description of problem:
The katello-installer and capsule-certs-generate are using rpms to distribute the generated certificates. Newly-regenerated rpms with new certificates have increased version number, so that they should updated the previous certificates in the system.
However, in some cases (especially when experimenting with different katello-installer certs options and trying to re-install the katello), the rpms with the newly generated certificates installed on the system don't update already installed rpms on the system from previous attempts.
Steps to Reproduce:
2. remove ~/ssl-build directory on the server
3. katello-installer --reset
4. capsule-certs-generate capsule-certs-generate --capsule-fqdn capsule.example.com --certs-tar ~/capsule.example.com.tar.gz
5. on the capsule: capsule-installer (using the options suggested in the capsule-certs-generate output)
The capsule-installer fails on
ProxyAPI::ProxyException: ERF12-2749 [ProxyAPI::ProxyException]: Unable to get environments from Puppet ([OpenSSL::SSL::SSLError]: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verif...) for proxy https://capsule.example.com:9090/puppet
The katello-installer, capsule-certs-generate and capsule-installer check that the cert rpms installed on the system correspond with the rpms that are intended to be used.
The workaround for the issue is to remote the cert rpms manually before the installer call:
for i in $(ls /etc/pki/katello-certs-tool/certs/*);
rpm -e $(rpm -qf $i)
The run of the installer should make the installer work again.
There is a kcs article about this workaround https://access.redhat.com/solutions/1311844 with a small suggested update here https://bugzilla.redhat.com/show_bug.cgi?id=1171841#c18
Before this patch, we were relying on the fact that the latest rpms
are always better. However, people often try to rollback to the
previous state of ssl-build and this behavior of the certs script was
causing more troubles than benefits.
After this change, we always use the latest version we have available
in ssl-build by checking if that's what's already installed on the
system or not.
While trying to rollback to some older version of certs, I was hitting
the nssdb errors, as we were not cleaning the certs in there properly.
Therefore I've reused the resource we already had there for certutil,
to clean up certs first.
When using something short and non-specific like 'ca' to grep the
nssdb output, other words in the nssdb can pass the test. For example,
[root@sat-r220-02 ~]# certutil -L -d /etc/pki/katello/nssdb
Certificate Nickname Trust Attributes
The 'ca' in 'Certificate Nickname' passes the 'grep ca' test.