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.
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
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).
That sound sane. Will do.
Commited as 5568829389d45b88bc628e4b1c07006cb155329d and 84eab5bff1293b884d3d93e7bfe292fd01536943. Will be fixed in spacewalk-proxy-installer-0.5.25-4
Verified
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