Bug 497929 - Proxy installer generates it's own CA when installing from Satellite
Proxy installer generates it's own CA when installing from Satellite
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Other (Show other bugs)
unspecified
All Linux
high Severity medium
: ---
: ---
Assigned To: Miroslav Suchý
Jeff Browning
: Regression
Depends On:
Blocks: 456999
  Show dependency treegraph
 
Reported: 2009-04-27 17:35 EDT by Justin Sherrill
Modified: 2009-09-10 10:38 EDT (History)
3 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 10:38:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Justin Sherrill 2009-04-27 17:35:35 EDT
This is fine for Hosted, but traditionally we have used the satellite's certificate authority when installing a satellite-connected proxy.  This change introduces new headaches for support and could potentially disrupt the provisioning component of satellite (as we always in the past have used a single CA certificate between the satellite and proxy).  It also means that 'switching' a system from a proxy to a satellite (or vice-versa) is not as simple as changing the URL it's using to connect through.  

Currently the Web-installer is still generating using the CA on the satellite which means the two methods are inconsistent.  

Was talking with cliff and it may be good enough to simply prompt the user if they are connecting through satellite (or detect it somehow) and  if so, ask them to go to their satellite, run some commands, and place the resulting tarball or rpm of the generated SSL keys in a certain place.  At least for 530.
Comment 1 Miroslav Suchý 2009-04-28 10:04:10 EDT
The CA key and public certificate is generated on line 271  of proxy/installer/configure-proxy.sh
If the file already exist it is reused. So if we put something in doc and even to the output of configure-proxy.sh like "please take /root/ssl-build/RHN-ORG-PRIVATE-SSL-KEY from satellite and put it in /roog/ssl-build of this machine' - then we should be safe. But this approach will be PITA for users.
Other (and for end user more friendly) approach may be, that the CA key and public certificate and even rpm for CA public certificate is created on Satellite itself during API call proxy.activate and is created configuration channel rhn_proxy_config_$SYSTEM_ID and the files are put there. And installer will download them after activation using rhncfg-client get /var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT
Comment 2 Brandon Perkins 2009-04-28 11:43:05 EDT
The proposal for 5.3 that Cliff and I came up with is to:

1) If there is no CA on the proxy and the parent is Hosted, then we generate it.
2) If there is no CA on the proxy and the parent is Satellite, then fail with an error message instructing them to copy the CA to the proxy at the correct location.
3) If there is a CA on the proxy and it does NOT match the parent, fail saying that there is a mismatch.  Then give the same instruction as #2.
4) If there is a CA on the proxy and it does match the parent, continue.

For both two and three, we should provide a "force" option to override and let the admin be able to ignore our recommendation.

Please let us know if there are any questions.  Cliff and I are also in agreement that we would like something cleaner (perhaps using the API and/or Config management in a future release).
Comment 3 Miroslav Suchý 2009-04-29 06:06:33 EDT
That sound sane.
Will do.
Comment 4 Miroslav Suchý 2009-05-05 10:16:04 EDT
Commited as 5568829389d45b88bc628e4b1c07006cb155329d and  84eab5bff1293b884d3d93e7bfe292fd01536943. 
Will be fixed in spacewalk-proxy-installer-0.5.25-4
Comment 5 Jeff Browning 2009-06-16 10:41:14 EDT
Verified
Comment 7 Brandon Perkins 2009-09-10 10:38:27 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1433.html

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