Bug 1160344

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.

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

+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

+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.

Created redmine issue http://projects.theforeman.org/issues/15931 from this bug

*** Bug 1425453 has been marked as a duplicate of this bug. ***

*** Bug 1160358 has been marked as a duplicate of this bug. ***

*** Bug 1040600 has been marked as a duplicate of this bug. ***

Connecting redmine issue http://projects.theforeman.org/issues/18907 from this bug

Connecting redmine issue http://projects.theforeman.org/issues/18717 from this bug

*** Bug 1240263 has been marked as a duplicate of this bug. ***

*** Bug 1576929 has been marked as a duplicate of this bug. ***

*** Bug 1309183 has been marked as a duplicate of this bug. ***

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.

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.

*** Bug 1288452 has been marked as a duplicate of this bug. ***

(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

*** Bug 1712193 has been marked as a duplicate of this bug. ***

*** Bug 1721532 has been marked as a duplicate of this bug. ***

Upstream bug assigned to sokeeffe

Upstream bug assigned to sokeeffe

Is that an existing install? You can only add cnames on fresh installs (I think)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.8 release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4366