CertificateError: hostname 'xxx' doesn't match 'yyy'

Support
1

Problem:
Noticed this problem when attempting to register a client with foreman-katello:

subscription-manager register --serverurl=xxx.external.domain.com --org="Default_Organization" --activationkey="DEV_TEST"

CLI returns:

Unable to reach the server at xxx.external.domain.com:443/rhsm

I know it isn’t a network issue, as telnet to the same port succeeds and the info below.
Server hostname is xxx.internal.domain.com, client’s can only access it via DNS alias, so they look for yyy.external.domain.com (DNS alias pointing to xxx.internal.domain.com).
This results in client log (/var/log/rhsn/rhsn.log) reporting:

CertificateError: hostname 'yyy.external.domain.com' doesn't match 'xxx.internal.domain.com'

Initial thought was looking into a way to either add CN/SAN to the certs, if this is possible, or find some other way to fix. So far I’m unable to find a way to add a CN/SAN to the cert(s). I did find reference to specifying something during initial server install (foreman-installer):

Expected outcome:
Client registration makes it past cert auth and I can continue learning about foreman/katello and its capabilities

Foreman and Proxy versions:

Foreman web interface reports: Version 2.3.5
xxx.internal.domain.com-foreman-proxy-1.0-1.noarch
xxx.internal.domain.com-foreman-proxy-client-1.0-1.noarch

Foreman and Proxy plugin versions:

# rpm -qa | grep foreman
tfm-rubygem-hammer_cli_foreman_docker-0.0.7-1.el7.noarch
xxx.internal.domain.com-foreman-proxy-1.0-1.noarch
foreman-postgresql-2.3.5-1.el7.noarch
foreman-installer-2.3.5-1.el7.noarch
foreman-cli-2.3.5-1.el7.noarch
tfm-rubygem-foreman_ansible-6.1.1-1.fm2_3.el7.noarch
tfm-rubygem-foreman-tasks-core-0.3.4-1.fm2_1.el7.noarch
foreman-release-2.3.5-1.el7.noarch
rubygem-foreman_maintain-0.8.27-1.el7sat.noarch
xxx.internal.domain.com-foreman-client-1.0-1.noarch
tfm-rubygem-hammer_cli_foreman_tasks-0.0.15-1.fm2_2.el7.noarch
tfm-rubygem-foreman_monitoring-2.1.0-1.fm2_3.el7.noarch
foreman-installer-katello-2.3.5-1.el7.noarch
foreman-selinux-2.3.5-1.el7.noarch
foreman-service-2.3.5-1.el7.noarch
foreman-2.3.5-1.el7.noarch
foreman-debug-2.3.5-1.el7.noarch
tfm-rubygem-hammer_cli_foreman_bootdisk-0.3.0-1.el7.noarch
tfm-rubygem-foreman_remote_execution_core-1.4.0-1.el7.noarch
tfm-rubygem-foreman-tasks-3.0.6-1.fm2_3.el7.noarch
foreman-dynflow-sidekiq-2.3.5-1.el7.noarch
tfm-rubygem-foreman_remote_execution-4.2.2-1.fm2_3.el7.noarch
foreman-proxy-2.3.5-1.el7.noarch
tfm-rubygem-hammer_cli_foreman-2.3.2-1.el7.noarch
xxx.internal.domain.com-foreman-proxy-client-1.0-1.noarch
2

Hi @JMCIVOR

This is defiantly a supported scenario, we want to run the installer with the following:

[root@satellite1 ~]# foreman-installer --full-help | grep -i cname
    --certs-cname                 The alternative names of the host the generated certificates

This will redeploy all the certs so if you have any capsules/smart proxies they will need to be reinstalled to be able to use the new certs.

2 Likes
3

Ahhhh good timing. I’ve got our server team restoring a pre-install back up of this server so I can re-perform the install. I assumed it would require a re-run/re-install of foreman-installer. Thanks for confirming that it may have worked if I simply re-ran the installer, that will be handy if I have to re-try this!

1 Like
4

Just reporing back @cintrix84
This indeed did the trick (Although I did have to add --scenario katello again) after rebuilding the server with the following command:

foreman-installer --scenario katello --certs-cname yyy.external.domain.com

Still, good to know that I might have been able to perform this change on the previous already existing katello/foreman server.
Thanks so much for the helpful info, sir!

2 Likes