Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1171841 - ProxyAPI::ProxyException: ERF12-2749 [ProxyAPI::ProxyException]
ProxyAPI::ProxyException: ERF12-2749 [ProxyAPI::ProxyException]
Status: CLOSED NEXTRELEASE
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Installer (Show other bugs)
6.0.6
x86_64 Linux
high Severity high (vote)
: Unspecified
: Unused
Assigned To: Ivan Necas
Katello QA List
: PrioBumpGSS, ReleaseNotes, Triaged
: 1243675 (view as bug list)
Depends On: 1218251
Blocks: sat61-release-notes 1315261
  Show dependency treegraph
 
Reported: 2014-12-08 12:59 EST by Chris Roberts
Modified: 2017-07-13 21:28 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1315261 (view as bug list)
Environment:
Last Closed: 2016-06-08 11:02:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1311844 None None None Never

  None (edit)
Comment 4 RHEL Product and Program Management 2014-12-08 13:13:54 EST
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 13:57:41 EST
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 02:54:18 EST
The workaround for this issue should be:

mv /etc/pki/katello/nssdb{,.bak}
katello-installer --certs-server-cert=""\
                  --certs-server-cert-req=""\
                  --certs-server-key=""\
                  --certs-server-ca-cert=""\
                  --certs-update-server --certs-update-server-ca\
Comment 11 Ivan Necas 2015-01-07 02:55:43 EST
Slightly corrected version (just the trailing \ at the end:)

mv /etc/pki/katello/nssdb{,.bak}
katello-installer --certs-server-cert=""\
                  --certs-server-cert-req=""\
                  --certs-server-key=""\
                  --certs-server-ca-cert=""\
                  --certs-update-server --certs-update-server-ca
Comment 12 Ivan Necas 2015-01-07 03:37:50 EST
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 12:40:14 EST
Ivan,

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 03:33:41 EST
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 16:24:05 EST
Ivan,

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 08:28:09 EDT
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 10:10:16 EDT
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-18 22:22:18 EDT
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.

thanks
Comment 23 Ivan Necas 2015-08-24 10:21:36 EDT
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 11:47:05 EST
*** Bug 1243675 has been marked as a duplicate of this bug. ***
Comment 31 David O'Brien 2016-04-17 20:48:08 EDT
Reset docs contact <> daobrien
Comment 32 Ivan Necas 2016-05-23 14:54:44 EDT
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 11:02:36 EDT
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.