Bug 1763084

Summary:	Fix invalid host certificates by filling-in subject alternate name during host installation, host upgrade or certificate enrolment
Product:	[oVirt] ovirt-engine	Reporter:	Martin Perina <mperina>
Component:	ovirt-host-deploy-ansible	Assignee:	Martin Perina <mperina>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Petr Matyáš <pmatyas>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.3.0	CC:	bugs, rdlugyhe
Target Milestone:	ovirt-4.4.0	Flags:	pm-rhel: ovirt-4.4+
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Previously, some migrations failed because of invalid host certificates whose Common Name (CN) contained an IP address, and because using the CN for hostname matching is obsolete. The current release fixes this issue by filling-in the Subject Alternative Name (SAN) during host installation, host upgrade, and certificate enrolment. Periodic certificate validation includes the SAN field and raises an error if it is not filled.	Story Points:	---
Clone Of:
Clones:	1763108 1763109 (view as bug list)		Environment:
Last Closed:	2020-05-20 20:02:46 UTC	Type:	Bug
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:
Bug Blocks:	1763108, 1763109

Description Martin Perina 2019-10-18 08:41:14 UTC

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

Comment 3 Petr Matyáš 2020-01-20 15:24:18 UTC

Verified on ovirt-host-deploy-common-1.9.0-0.0.master.20191128124417.gitd2b9fa5.el7ev.noarch

Comment 4 Rolfe Dlugy-Hegwer 2020-03-04 00:30:55 UTC

I want to display an edited version of the original doc text here:

Host certificates used for encrypted communication between engine and VDSM are generated automatically during host installation. We are using the hostname, which can be either an FQDN or IP address, to populate the Common Name (CN) field of the certificate. But there are issues with this approach:

1. CN should not contain an IP address
2. Using CN for hostname matching in certificates is obsolete and should be no longer used [1].

That's why we have changed a way how to generate certificates and we started to populate Subject Alternative Name (SAN) [2] field in the certificate with correct identification if the supplied hostname is FQDN or IP address.

In order to fix certificates for existing hosts we have added several improvements:

1. All newly added host will have certificates with correct SAN field
2. During our periodical check for certificate validity, we also check if SAN field is populated and if not error is raised and stored in the audit log, so administrators will know that host's certificate needs to be reenrolled
3. We also check for certificate validity during host upgrade, so we have also added here the check for the SAN field, so the host's certificate can be reenrolled during host upgrade.

[1] http://wiki.cacert.org/FAQ/subjectAltName
[2] https://libvirt.org/remote.html#Remote_TLS_server_certificates

Comment 7 Sandro Bonazzola 2020-05-20 20:02:46 UTC

This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020.

Since the problem described in this bug report should be
resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.