Bug 1171841

Summary: ProxyAPI::ProxyException: ERF12-2749 [ProxyAPI::ProxyException]
Product: Red Hat Satellite Reporter: Chris Roberts <chrobert>
Component: InstallationAssignee: Ivan Necas <inecas>
Status: CLOSED NEXTRELEASE QA Contact: Katello QA List <katello-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 6.0.6CC: anerurka, bbuckingham, bkearney, chartwel, chrobert, cwelton, dmoessne, ftsiadim, inecas, jason.hayes, jsherril, kshirsal, kshravag, mmccune, mmello, mtenheuv, nshaik, xdmoon
Target Milestone: UnspecifiedKeywords: PrioBumpGSS, ReleaseNotes, Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1315261 (view as bug list) Environment:
Last Closed: 2016-06-08 15:02:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1218251    
Bug Blocks: 1190823, 1315261    

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-server-cert-req=""\
                  --certs-server-key=""\
                  --certs-server-ca-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-server-cert-req=""\
                  --certs-server-key=""\
                  --certs-server-ca-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
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 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
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 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.

thanks

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.