Description of problem: (http://rhvm.example.org/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA) by default serves the CA certificate located at /etc/pki/ovirt-engine/ca.pem. On a default RHV-M installation, /etc/pki/ovirt-engine/apache-ca.pem is a symbolic link pointing to /etc/pki/ovirt-engine/ca.pem. # ls -l /etc/pki/ovirt-engine/apache-ca.pem lrwxrwxrwx. 1 root root 28 Jan 20 16:18 /etc/pki/ovirt-engine/apache-ca.pem -> /etc/pki/ovirt-engine/ca.pem However, when using custom TLS certificates for Apache, the URL still serves /etc/pki/ovirt-engine/ca.pem which is not valid. Steps to Reproduce: 1. On a default RHV-M installation, access URL to download the CA certificate (http://rhvm.example.org/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA) 2. Replace the Apache certificate and CA certificate as per (https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html-single/administration_guide/index#Replacing_the_Manager_CA_Certificate) 3. Access URL to download the CA certificate (http://rhvm.example.org/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA) Actual results: When using custom TLS certificates the URL still serves /etc/pki/ovirt-engine/ca.pem which is not valid. Expected results: When using custom TLS certificates the URL should serve /etc/pki/ovirt-engine/apache-ca.pem. Additional info: Removing the symbolic link /etc/pki/ovirt-engine/apache-ca.pem and replacing it with the custom CA certificate does not make a difference to the URL. Overwriting /etc/pki/ovirt-engine/ca.pem with the custom Apache CA certificate makes the URL to serve the correct certificate. **Not a recommended approach.
That's by design, because the URL http://rhvm.example.org/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA is defined to retrieve engine CA certificate, which is used: 1. To sign engine HTTPS certificate (by default, but HTTPS certificate can be replaced by custom certificate signed by custom CA) 2. To sign certificates of hypervisors to allow encrypted communication between engine and VDSM on hypervisors So when customer supplies it's own HTTPS certificate signed by custom CA, we cannot provide that custom CA on above URL, because we would break the valid URL to get engine CA for engine-VDSM communication. When customer supplies custom HTTPS certificate signed by custom CA, it's his responsibility to distribute the custom CA on on all clients. Also there is a difference in returning a link to CA certificate for console resources in .vv file: 1. When engine CA is used, we are pointing to CA URL http://rhvm.example.org/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA as a part of .vv file 2. When custom CA is used, we are not icnluding CA URL in .vv file and in this case virt-viewer expects that custom CA certificate is already included in trusted CAs of the client So I suggest to close this as NOTABUG
Thanks for the explanation Martin. Perhaps it would help to clear up confusion by renaming the 'CA Certificate' link to 'Engine CA Certificate'?
(In reply to Sam Wachira from comment #3) > Thanks for the explanation Martin. > > Perhaps it would help to clear up confusion by renaming the 'CA Certificate' > link to 'Engine CA Certificate'? Do you mean to change it in the URL from http://rhvm.example.org/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA to http://rhvm.example.org/ovirt-engine/services/pki-resource?resource=engine-ca-certificate&format=X509-PEM-CA ? If so, then we cannot easily do it, it would break all existing clients depending on that URL. We are using that URL on quite a lot of places non only internally within RHV, but also external applications might depend on it. Also we don't have a description of that URL parameters in official RHV, so the only improvement which comes to my mind would be to add a note to https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl#Replacing_the_Manager_CA_Certificate that after switching to custom HTTPS certificate singed by custom CA, below URL will still return engine CA and not a custom one: http://rhvm.example.org/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA Are you OK with that solution?
Hi Martin, I mean keeping the URL the same (https://rhvm.example.org/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA) but, rename 'CA Certificate' to 'Engine CA Certificate' on the RHV-M UI landing page (https://rhvm2.rhvmgmt.tamlab.rdu2.redhat.com/ovirt-engine/) . Updating documentation after switching to custom HTTPS certificate signed by custom CA would also help.
(In reply to Sam Wachira from comment #5) > Hi Martin, > > I mean keeping the URL the same > (https://rhvm.example.org/ovirt-engine/services/pki-resource?resource=ca- > certificate&format=X509-PEM-CA) but, > > rename > > 'CA Certificate' > > to > > 'Engine CA Certificate' > > on the RHV-M UI landing page > (https://rhvm2.rhvmgmt.tamlab.rdu2.redhat.com/ovirt-engine/) . That shouldn't be a problem. Welcome page content is managed by UX team, Sharon, could you please take over? > > Updating documentation after switching to custom HTTPS certificate signed by > custom CA would also help. I've created BZ1936349 to handle that
Steps: 1) Check that link to engine ca certificate is renamed to Engine CA certificate on landing page Results: The link text is renamed and the content is still the original. Verified in: ovirt-engine-4.4.6.6-0.10.el8ev.noarch
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 (Moderate: RHV Manager security update (ovirt-engine) [ovirt-4.4.6]), 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-2021:2179
Due to QE capacity, we are not going to cover this issue in our automation