Bug 1763109

Summary:	[downstream clone - 4.3.7] Fix invalid host certificates by filling-in subject alternate name during host upgrade or certificate reenrollment
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	RHV bug bot <rhv-bugzilla-bot>
Component:	ovirt-engine	Assignee:	Martin Perina <mperina>
Status:	CLOSED ERRATA	QA Contact:	Petr Matyáš <pmatyas>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.3.0	CC:	bugs, mperina, nhalevy, pelauter, Rhev-m-bugs
Target Milestone:	ovirt-4.3.7	Keywords:	ZStream
Target Release:	4.3.7
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovirt-engine-4.3.7.1	Doc Type:	Enhancement
Doc Text:	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.	Story Points:	---
Clone Of:	1763084	Environment:
Last Closed:	2019-12-12 10:36:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1763084
Bug Blocks:

Description RHV bug bot 2019-10-18 09:24:53 UTC

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

Comment 2 Martin Perina 2019-10-18 12:31:16 UTC

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

Comment 4 Petr Matyáš 2019-11-04 12:15:25 UTC

Verified on ovirt-engine-4.3.7.1-0.1.el7.noarch

Comment 5 RHV bug bot 2019-11-14 11:10:07 UTC

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

Comment 6 Nadav Halevy 2019-12-10 12:52:47 UTC

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.

Comment 8 errata-xmlrpc 2019-12-12 10:36:35 UTC

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