Bug 497929

Summary:	Proxy installer generates it's own CA when installing from Satellite
Product:	Red Hat Satellite 5	Reporter:	Justin Sherrill <jsherril>
Component:	Other	Assignee:	Miroslav Suchý <msuchy>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jeff Browning <jbrownin>
Severity:	medium	Docs Contact:
Priority:	high
Version:	unspecified	CC:	bperkins, gkhachik, msuchy
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	sat530	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-09-10 14:38:27 UTC	Type:	---
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:
Bug Blocks:	456999

Description Justin Sherrill 2009-04-27 21:35:35 UTC

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 14:04:10 UTC

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 15:43:05 UTC

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 10:06:33 UTC

That sound sane.
Will do.

Comment 4 Miroslav Suchý 2009-05-05 14:16:04 UTC

Commited as 5568829389d45b88bc628e4b1c07006cb155329d and  84eab5bff1293b884d3d93e7bfe292fd01536943. 
Will be fixed in spacewalk-proxy-installer-0.5.25-4

Comment 5 Jeff Browning 2009-06-16 14:41:14 UTC

Verified

Comment 7 Brandon Perkins 2009-09-10 14:38:27 UTC

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