Bug #15538
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)
Description
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.
How reproducible:
always
Steps to Reproduce:
1. katello-installer
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)
Actual results:
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
Expected results:
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.
Additional info:
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/*);
do
rpm -e $(rpm -qf $i)
done
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
Associated revisions
Refs #15538: Check for nssdb cert as the beginning of a line (#92)
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
SSL,S/MIME,JAR/XPI
amqp-client ,,
broker u,u,u
The 'ca' in 'Certificate Nickname' passes the 'grep ca' test.
History
#1
Updated by Ivan Necas over 4 years ago
- Status changed from New to Ready For Testing
- Pull request https://github.com/Katello/puppet-certs/pull/91 added
#2
Updated by Justin Sherrill over 4 years ago
- Status changed from Ready For Testing to Closed
- Legacy Backlogs Release (now unused) set to 171
- Difficulty set to medium
#3
Updated by Eric Helms over 4 years ago
- Pull request https://github.com/Katello/puppet-certs/pull/92 added
#4
Updated by Eric Helms over 4 years ago
- Legacy Backlogs Release (now unused) changed from 171 to 162
Fixes #15538 - make sure the rpms from ssl-build are used (#91)
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.