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)

Added by Ivan Necas over 4 years ago. Updated over 2 years ago.

Target version:
Bugzilla link:


Cloned from
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:

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 --certs-tar ~/
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

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/*); 
rpm -e $(rpm -qf $i)

The run of the installer should make the installer work again.

There is a kcs article about this workaround with a small suggested update here

Associated revisions

Revision df36e803 (diff)
Added by Ivan Necas over 4 years ago

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.

Revision e1f168d7 (diff)
Added by Eric D Helms over 4 years ago

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

amqp-client ,,
broker u,u,u

The 'ca' in 'Certificate Nickname' passes the 'grep ca' test.


#1 Updated by Ivan Necas over 4 years ago

  • Status changed from New to Ready For Testing
  • Pull request 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 added

#4 Updated by Eric Helms over 4 years ago

  • Legacy Backlogs Release (now unused) changed from 171 to 162

Also available in: Atom PDF