Bug 1171841
Summary: | ProxyAPI::ProxyException: ERF12-2749 [ProxyAPI::ProxyException] | |||
---|---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Chris Roberts <chrobert> | |
Component: | Installation | Assignee: | Ivan Necas <inecas> | |
Status: | CLOSED NEXTRELEASE | QA Contact: | Katello QA List <katello-qa-list> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 6.0.6 | CC: | anerurka, bbuckingham, bkearney, chartwel, chrobert, cwelton, dmoessne, ftsiadim, inecas, jason.hayes, jsherril, kshirsal, kshravag, mmccune, mmello, mtenheuv, nshaik, xdmoon | |
Target Milestone: | Unspecified | Keywords: | 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
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. 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\ 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 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) 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. 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 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. 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. Given the workaround should work, and https://bugzilla.redhat.com/show_bug.cgi?id=1218251 tracking the usability, +1 for closing this BZ 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 I would suggest using the https://access.redhat.com/solutions/1311844 as the base for doc info here *** Bug 1243675 has been marked as a duplicate of this bug. *** Reset docs contact <> daobrien 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. 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. |