Bug 1171841 - ProxyAPI::ProxyException: ERF12-2749 [ProxyAPI::ProxyException]
Summary: ProxyAPI::ProxyException: ERF12-2749 [ProxyAPI::ProxyException]
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Installer
Version: 6.0.6
Hardware: x86_64
OS: Linux
high vote
Target Milestone: Unspecified
Assignee: Ivan Necas
QA Contact: Katello QA List
: 1243675 (view as bug list)
Depends On: 1218251
Blocks: sat61-release-notes 1315261
TreeView+ depends on / blocked
Reported: 2014-12-08 17:59 UTC by Chris Roberts
Modified: 2020-12-11 11:45 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1315261 (view as bug list)
Last Closed: 2016-06-08 15:02:36 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1218251 0 high CLOSED The installer should check that the cert rpms installed on the system are corresponding to those present in ~/ssl-build ... 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution) 1311844 0 None None None Never

Internal Links: 1218251 1358807

Comment 4 RHEL Program Management 2014-12-08 18:13:54 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 6 Justin Sherrill 2014-12-22 18:57:41 UTC
It sounds to me like some set of certificates are not updated.  

On the "Settings", under the "Provisioning" tab, there should be three settings for ssl:

ssl_ca_file: /etc/foreman/proxy_ca.pem
ssl_certificate:  /etc/foreman/client_cert.pem
ssl_priv_key:  /etc/foreman/client_key.pem

These are the files the foreman server is using to communicate with the smart proxy.  On the smart proxy side in /etc/foreman-proxy/settings.yml:

:ssl_ca_file: /etc/foreman-proxy/ssl_ca.pem
:ssl_certificate: /etc/foreman-proxy/ssl_cert.pem
:ssl_private_key: /etc/foreman-proxy/ssl_key.pem

These are the files that the smart proxy uses to verify the rails process when it tries to communicate with it.

One set of these files I am guessing has not been updated.

Comment 10 Ivan Necas 2015-01-07 07:54:18 UTC
The workaround for this issue should be:

mv /etc/pki/katello/nssdb{,.bak}
katello-installer --certs-server-cert=""\
                  --certs-update-server --certs-update-server-ca\

Comment 11 Ivan Necas 2015-01-07 07:55:43 UTC
Slightly corrected version (just the trailing \ at the end:)

mv /etc/pki/katello/nssdb{,.bak}
katello-installer --certs-server-cert=""\
                  --certs-update-server --certs-update-server-ca

Comment 12 Ivan Necas 2015-01-07 08:37:50 UTC
In fact, the `mv /etc/pki/katello/nssdb{,.bak}` should not be even needed in this case (I was usually doing this procedure, when changing fqdn of the host, which needed this)

Comment 13 Jason Hayes 2015-01-07 17:40:14 UTC

I agree with you that the command you listed should work in order to install the new certificates.  The problem is that this command is not working to install the new certificates.  They appear to be partially applied when you use that syntax to update to a cert that has been signed with MS Active Directory Certificate Services.  They work properly for the web GUI sessions (the certificate shows the signing information properly in the browser), but different components of Satellite/Katello are not able to communicate internally - Puppet gives certificate errors, Foreman gives certificate errors, etc.

Comment 14 Ivan Necas 2015-01-08 08:33:41 UTC
The command listed above should provide you a way how to get back to the self-signed certificates.

Ad. validating the self-signed certificates, you could try this script: you could try this script the issue is https://raw.githubusercontent.com/iNecas/katello-installer/issue/8609/bin/katello-certs-check

Comment 15 Jason Hayes 2015-01-08 21:24:05 UTC

It does not work properly; after the signed CA cert is installed you can no longer update the certs for all of the subcomponents of Katello.  The foreman and puppet certs are not updated during that process.

As for the katello-certs-check script it fails the cert if it was signed by Active Directory.  However, I can test the script with openssl and it passes the openssl tests.

Comment 19 Ivan Necas 2015-05-04 12:28:09 UTC
I've opened a new BZ with suggestion on the fix in the upstream: also made the bz public so that others can see the workaround and context.

Comment 21 Ivan Necas 2015-08-11 14:10:16 UTC
Given the workaround should work, and https://bugzilla.redhat.com/show_bug.cgi?id=1218251 tracking the usability, +1 for closing this BZ

Comment 22 David O'Brien 2015-08-19 02:22:18 UTC
Can I get some suitable doc text to add to the release note for this? The issues seems to have bounced around a bit and I'd like to make sure the correct info is added.


Comment 23 Ivan Necas 2015-08-24 14:21:36 UTC
I would suggest using the https://access.redhat.com/solutions/1311844 as the base for doc info here

Comment 30 Bryan Kearney 2015-12-11 16:47:05 UTC
*** Bug 1243675 has been marked as a duplicate of this bug. ***

Comment 31 David O'Brien 2016-04-18 00:48:08 UTC
Reset docs contact <> daobrien

Comment 32 Ivan Necas 2016-05-23 18:54:44 UTC
Step number one is to fix https://bugzilla.redhat.com/show_bug.cgi?id=1218251 so that we are sure the cert RPMs are the ones that are actually used.

Comment 33 Bryan Kearney 2016-06-08 15:02:36 UTC
I am closing this bug out. Several things are being done to resolve the certs issues.

First, https://access.redhat.com/solutions/2263671 has been updated by GSS and Engineering. This now contains the correct steps resolve the certs issues which are found.

Second, https://bugzilla.redhat.com/show_bug.cgi?id=1218251 is going to be fixed as part of 6.2. This is one of the main causes of putting the machines into the incorrect state.

Third, https://bugzilla.redhat.com/show_bug.cgi?id=1315261, will be tracked to 
to bake into the installer a way to reset the certificates fully.

Note You need to log in before you can comment on or make changes to this bug.