+++ This bug is an upstream to downstream clone. The original bug is: +++ +++ bug 1763084 +++ ====================================================================== We currently put Hostname/IP into Common Name (CN) in the host certificate subject. This is not good for two reasons: - Using CN for host name matching in certificates is obsolete and should be no longer used [1]. - CN may not contain an IP address. In the latter case, migrations don't work on el8 since libvirt refuses to connect to a destination host having invalid data in its certificate. The correct way to handle the certificates is to put the host name or IP addresses to the Subject Alternative Name [2]. This is what this patch does. [1] http://wiki.cacert.org/FAQ/subjectAltName [2] https://libvirt.org/remote.html#Remote_TLS_server_certificates (Originally by Martin Perina)
*** Bug 1763108 has been marked as a duplicate of this bug. ***
Verified on ovirt-engine-4.3.7.1-0.1.el7.noarch
INFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Tag 'ovirt-engine-4.3.7.2' doesn't contain patch 'https://gerrit.ovirt.org/104183'] gitweb: https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/tags/ovirt-engine-4.3.7.2 For more info please contact: rhv-devops
Hi Martin, can you please review this doc text as soon as possible as we need it for errata approval for 4.3.7? The following improvements have been made to host certificates used for encrypted communication between the RHV Manager and the Virtual Desktop Server Manager: 1. All newly added host will have certificates with correct SAN field 2. A periodic check for certificate validity is performed and if the SAN field is not populated an error is reported in the audit log, notifying administrators that the host certificate needs to be re-enrolled. 3. The SAN field in the certificate is also checked during host upgrade, so that the host certificate can be re-enrolled during host upgrade.
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, 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/RHBA-2019:4229