Description of problem:

When Foreman makes an API call to Smart Proxy for BMC operations, even when an FQDN is configured in the Foreman Web UI, it is not used. Instead, Smart Proxy attempts to connect to Redfish API of BMC using an IP address. This results in an authentication error due to a mismatch with the server's TLS/SSL certificate, whose Common Name (CN) is based on the FQDN, causing the BMC operations to fail.

How reproducible:

 Always

Is this issue a regression from an earlier version:

No

Steps to Reproduce:

Copied from https://projects.theforeman.org/issues/38972#Steps-to-Reproduce and some formatting may be lost.

1. Prepare a machine whose power can be controlled via the Redfish BMC interface. Use a TLS/SSL certificate for Redfish API of BMC that has only the FQDN registered as its Common Name (CN) and in the Subject Alternative Name (SAN).

Certificate creation example:

openssl req -x509 -nodes -newkey rsa:2048 -days 365 -subj "/CN=www.example.com" -addext "subjectAltName = DNS:www.example.com" -keyout /tmp/tmp.pem -out /tmp/tmp.crt

2. In the Foreman Web UI, configure the FQDN as the BMC connection destination for the Redfish BMC interface of the machine in step 1). Refer to the following configuration example. Then, execute a power control operation (e.g., ON/OFF).

Actual behavior:

An error message including the following will appear in the smart-proxy logs (`/var/log/foreman-proxy/proxy.log`), and the operation will fail:
noformat
does not match the server certificate (OpenSSL::SSL::SSLError)
noformat

Expected behavior:

When an FQDN is configured as the BMC connection target in the Foreman Web UI, Foreman should use that FQDN for the `:host` parameter when making requests to the Smart Proxy's BMC API.
This would allow Smart Proxy to connect to Redfish API of BMC using the FQDN, preventing authentication errors due to a mismatch between the TLS/SSL certificate's CN and the connection target FQDN, thereby enabling successful BMC operations.

Business Impact / Additional info:

Requests for power operations and information retrieval for each machine from the Foreman Web UI are performed by Foreman core calling the Smart Proxy's BMC API. The path format for the Smart Proxy's BMC API is `/bmc/:host/<additional-path-per-request>`, where `:host` is intended to specify the hostname of the target BMC.

However, even when an FQDN is configured in Foreman's BMC interface settings, Foreman invariably specifies an IP address for `:host` when utilizing the Smart Proxy's BMC API.

Consequently, when Smart Proxy performs TLS/SSL authentication (server authentication) against the Redfish interface of the BMC, a validation is carried out between the FQDN registered in the BMC's X.509 certificate (e.g., `www.example.com`) and the IP address passed from Foreman UI (e.g., `192.168.1.101`). As a result, because the FQDN and the IP address are different, it invariably leads to an authentication failure due to a mismatch, giving rise to the error "`does not match the server certificate (OpenSSL::SSL::SSLError)`", and thus preventing power operations and information retrieval.