Bug 1160344 - [RFE] Satellite support for cname as alternate cname for satellite server
Summary: [RFE] Satellite support for cname as alternate cname for satellite server
Keywords:
Status: ON_QA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Certificates
Version: 6.0.3
Hardware: Unspecified
OS: Unspecified
high
medium with 1 vote vote
Target Milestone: 6.8.0
Assignee: Sean O'Keeffe
QA Contact: Stephen Wadeley
URL: https://projects.theforeman.org/issue...
Whiteboard:
: 1040600 1160358 1240263 1288452 1309183 1425453 1576929 1712193 1721532 (view as bug list)
Depends On: 1240263
Blocks: 1122832 1353215 260381 sat-nextgen 1040600 1296845 1316897 1317530
TreeView+ depends on / blocked
 
Reported: 2014-11-04 15:17 UTC by Dave Sullivan
Modified: 2020-07-07 01:24 UTC (History)
58 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-25 16:54:23 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 15931 Normal Resolved katello installer doesn't fully support cname alternate cname for satellite server 2020-07-02 15:32:25 UTC
Foreman Issue Tracker 18717 Normal Ready For Testing [RFE] Smart Proxies to have multiple interfaces 2020-07-02 15:32:25 UTC
Red Hat Bugzilla 1179944 'medium' 'CLOSED' '[RFE] allow capsule to support cname' 2019-12-05 18:39:54 UTC
Red Hat Knowledge Base (Solution) 895283 None None None 2019-11-14 06:23:44 UTC
Red Hat Knowledge Base (Solution) 1489623 None None None 2019-12-16 04:48:25 UTC
Red Hat Knowledge Base (Solution) 1549793 None None None 2019-12-16 04:48:25 UTC
Red Hat Knowledge Base (Solution) 1566273 None None None 2018-09-21 13:17:53 UTC
Red Hat Knowledge Base (Solution) 3543941 None None None 2018-07-25 16:50:14 UTC

Internal Links: 1179944

Description Dave Sullivan 2014-11-04 15:17:12 UTC
Description of problem:

hostname: xyz123-us.acme.com
cname: satellite.acme.com


katello-installer --foreman-db-password foreman --foreman-db-username foreman --katello-proxy-url http://applicationwebproxy.acme.com --katello-proxy-port 8080 --certs-ca-common-name "satellite.acme.com" --certs-node-fqdn "satellite.acme.com" --capsule-parent-fqdn "satellite.acme.com" --foreman-foreman-url="https://satellite.acme.com" --foreman-admin-password changeme

it does not update /etc/pulp/server.conf [messaging] and [tasks] sections with CNAME and i get 

Nov  4 00:41:59 totlx90101 pulp: celery.worker.consumer:ERROR: consumer: Cannot connect to qpid://guest@xyz123-us.acme.com:5671//: Connection hostname 'xyz123-us.acme.com' does not match names from peer certificate: ['satellite.acme.com', u'satellite.acme.com'].
Nov  4 00:41:59 xyz123-us pulp: celery.worker.consumer:ERROR: Trying again in 12.00 seconds...
Nov  4 00:41:59 xyz123-us pulp: celery.worker.consumer:ERROR:


I have manually modified /etc/pulp/server.conf and everything seems to be working now.


Version-Release number of selected component (if applicable):

Current Satellite 6


How reproducible:

See above


Actual results:




Expected results:

pulp should correctly set /etc/pulp/server.conf


Additional info:

Customer can use a cname as a way to have a hotbackup of the Satellite server for DR purposes.  This removes requirements to change certs.

The alternative approach requires cert changes.

Updating the hostname of a Red Hat Satellite 6 Server and updating associated SSL certificates.
https://access.redhat.com/solutions/1232133

and this one
https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.0/html/User_Guide/sect-Disaster_Recovery.html 

Reference to other BZs for cname support

[RFE] CNAME and SRV record support in foreman
https://bugzilla.redhat.com/show_bug.cgi?id=1045613

Comment 2 Mike McCune 2014-11-06 16:34:53 UTC
We require a FQDN and not a CName for Satellite as noted in our Installation Guide:

https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.0/html-single/Installation_Guide/index.html#Prerequisites3

We are unlikely to change this in the near term and this could be considered an RFE if it is a feature we should evaluate. If you feel we should re-evaluate this bug as an RFE feel free to re-open with justification.

Comment 6 Dave Sullivan 2015-07-31 18:16:10 UTC
Another use case

if your capsule goes down and you build new capsule, you can change CNAME there, if you don't have CNAME you have to go to every host and change redhat.repo file to point to new Capsule

The same goes for Satellite, if you build Satellite to a new FQDN (whenever we actually support that, unless you have a different A record used during satellite install you would have modify all your hosts redhat.repo to change with the FQDN

Comment 7 Sergio G. 2015-08-12 11:27:38 UTC
+1 to get this well covered as using VIP/CNAME is very common in enterprise environments where hostnames are well defined and established according to rules.

Regards,
Sergio

Comment 8 Kristof Van Damme 2016-04-15 09:56:28 UTC
+1 It is simply unacceptable for a product in the year 2016 to be designed in such way it cannot serve on a URL different from the hostname. Please fix this ASAP.

Comment 12 Stephen Benjamin 2016-08-01 13:57:35 UTC
Created redmine issue http://projects.theforeman.org/issues/15931 from this bug

Comment 14 Stephen Benjamin 2017-02-23 13:35:00 UTC
*** Bug 1425453 has been marked as a duplicate of this bug. ***

Comment 16 Mike McCune 2017-07-10 18:16:30 UTC
*** Bug 1160358 has been marked as a duplicate of this bug. ***

Comment 19 Bryan Kearney 2017-11-02 17:10:24 UTC
*** Bug 1040600 has been marked as a duplicate of this bug. ***

Comment 24 pm-sat@redhat.com 2018-01-18 19:23:10 UTC
Connecting redmine issue http://projects.theforeman.org/issues/18907 from this bug

Comment 25 pm-sat@redhat.com 2018-01-18 19:23:43 UTC
Connecting redmine issue http://projects.theforeman.org/issues/18717 from this bug

Comment 26 Bryan Kearney 2018-01-18 19:24:21 UTC
*** Bug 1240263 has been marked as a duplicate of this bug. ***

Comment 27 Chris Duryee 2018-05-10 20:57:11 UTC
*** Bug 1576929 has been marked as a duplicate of this bug. ***

Comment 29 Rich Jerrido 2018-07-18 12:31:56 UTC
*** Bug 1309183 has been marked as a duplicate of this bug. ***

Comment 30 Chris Roberts 2018-07-25 16:54:23 UTC
This is fixed in 6.3, I verified it when fixing a customer issue with 2 fqdns and was able to create the satellite and capsule certs with the cname in the SAN of the SSL cert. I am marking this closed. I have retired all the old KCS linked to this that says this is not supported.

Comment 33 Nagoor Shaik 2018-09-12 14:08:48 UTC
I tested Subject Alt Names setup with Satellite 6.3. And it works very well. 

But only the clause when is manual that needs to be executed on client systems 

  1. Installing katello-ca-consumer RPM deploys the hostname in /etc/rhsm/rhsm.conf with original name
  2. After installing the bootstrap RPM customer has to run 
      # sed -i 's/<satellite-original-name>/<satellite-cname>/g' /usr/bin/katello-rhsm-consumer
      # bash /usr/bin/katello-rhsm-consumer
  3. Registering now with CNAME, system successfully registers to Satellite.

Comment 35 Rich Jerrido 2018-09-21 13:17:54 UTC
*** Bug 1288452 has been marked as a duplicate of this bug. ***

Comment 45 Peter Vreman 2019-06-19 15:32:14 UTC
(In reply to Nagoor Shaik from comment #33)
> I tested Subject Alt Names setup with Satellite 6.3. And it works very well. 
> 
> But only the clause when is manual that needs to be executed on client
> systems 
> 
>   1. Installing katello-ca-consumer RPM deploys the hostname in
> /etc/rhsm/rhsm.conf with original name
>   2. After installing the bootstrap RPM customer has to run 
>       # sed -i 's/<satellite-original-name>/<satellite-cname>/g'
> /usr/bin/katello-rhsm-consumer
>       # bash /usr/bin/katello-rhsm-consumer
>   3. Registering now with CNAME, system successfully registers to Satellite.



My first try to get the above use case working was to set the documented in --help value certs-node-fqdn, but that broke already in installer on katello->candlepin. Then in a second step i added --cert-cnames=<satellite-original-name> to make katello-candlepin working. It works but it is confusing because satellite-installer configures the fqdn for internal communications, then i tried to update some more internal urls to use the cname and then it became a big mess as tehre were even more sinternal comminication configuration files that still uses a 'hardcoded' fqdn and also requiring additional ~10 installer parameters to 'fix' urls is not future proof.


Finally i ended looking for the puppet module responsible for the katello-ca-consumer part found the parameter 'certs::katello::hostname' (default is certs-node-fqdn) that is used in the generated katello-rhsm-consumer and rpm name and therefor also used in updating the configuration on the client after the rpm is installed.

The real root cause is that Satellite Installer is using the same set of input parameter 'certs-node-fqdn' to configure certificates for internal communications (candlepin-katello or pulp-katello) as well as external communications with the client.
A solution might be to have 'consumer-cert-node-fqdn'  and 'consumer-cert-cname' to be able to configure the CNAMEs to be used for the client configuration only.


At least the above use case can be implemented using custom hiera for satellite-installer
add 'certs::katello::hostname: <satellite-cname>' to /etc/foreman-installer/custom-hiera.yaml

Comment 46 Rich Jerrido 2019-07-03 17:15:15 UTC
*** Bug 1712193 has been marked as a duplicate of this bug. ***

Comment 47 Zach Huntington-Meath 2019-07-11 13:55:09 UTC
*** Bug 1721532 has been marked as a duplicate of this bug. ***

Comment 50 Bryan Kearney 2019-11-05 20:45:46 UTC
Upstream bug assigned to sokeeffe@redhat.com

Comment 51 Bryan Kearney 2019-11-05 20:45:50 UTC
Upstream bug assigned to sokeeffe@redhat.com


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