RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1560598 - virt-who-0.19-8.el7_4 fails to validate server certificate when running on RHV Host 4.1
Summary: virt-who-0.19-8.el7_4 fails to validate server certificate when running on RH...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who
Version: 7.4
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Kevin Howell
QA Contact: Eko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-26 14:20 UTC by Pablo Hess
Modified: 2021-09-09 13:31 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 10:47:49 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github candlepin virt-who pull 139 0 None closed 1560598: Pass hostname to M2Crypto in STOMP client 2021-02-19 10:02:07 UTC
Red Hat Knowledge Base (Solution) 3390391 0 None None None 2018-03-26 14:26:36 UTC
Red Hat Product Errata RHBA-2018:3169 0 None None None 2018-10-30 10:48:17 UTC

Description Pablo Hess 2018-03-26 14:20:53 UTC
Description of problem:
RHV 4.1 node running virt-who locally and reporting to Satellite 6.2. virt-who-0.19-7 works as expected, retrieves host-to-guest mapping and sends it over to Satellite.
virt-who-0.19-8, however, cannot retrieve host-to-guest mapping and instead throws:

WrongHost: Peer certificate commonName does not match host, expected 10.1.2.3, got rhvh.example.com




Version-Release number of selected component (if applicable):
RHV Host 4.1
virt-who-0.19-8.el7_4


How reproducible:
Everytime

Steps to Reproduce:
1. Deploy virt-who to RHV 4.1 host
2. Run the virt-who service or call 'virt-who -o -d'
3.

Actual results: (from virt-who output)

2018-03-21 19:26:06,941 [INFO] @main.py:183 - Using configuration "rhvh.example.com" ("vdsm" mode)
2018-03-21 19:26:06,942 [INFO] @main.py:185 - Using reporter_id='rhvh.example.com-a75789f82a744e2e9060a5da1e3850b9'
2018-03-21 19:26:07,033 [ERROR] @virt.py:389 - Thread 'rhvh.example.com' fails with exception:
WrongHost: Peer certificate commonName does not match host, expected 10.1.2.3, got rhvh.example.com
2018-03-21 19:26:07,034 [INFO] @virt.py:885 - Report for config "rhvh.example.com" gathered, placing in datastore
2018-03-21 19:26:07,034 [INFO] @virt.py:408 - Waiting 3600 seconds before performing action again 'rhvh.example.com'
2018-03-21 20:26:12,404 [ERROR] @virt.py:389 - Thread 'rhvh.example.com' fails with exception:
WrongHost: Peer certificate commonName does not match host, expected 10.1.2.3, got rhvh.example.com
2018-03-21 20:26:12,404 [INFO] @virt.py:885 - Report for config "rhvh.example.com" gathered, placing in datastore
2018-03-21 20:26:12,406 [INFO] @virt.py:408 - Waiting 3600 seconds before performing action again 'rhvh.example.com'


Expected results:
virt-who works and collects guest-to-host mapping info and sends it to Satellite.

Additional info:
virt-who-0.19-7.el7_4 works fine with the exact same virt-who config files, so the workaround for the customer was to simply 'yum downgrade virt-who-0.19-7.el7_4' and stick to that version.

Comment 4 Pablo Hess 2018-03-27 14:12:08 UTC
Additional info on virt-who confs.

The issue was seen with virt-who confs *not* pointing to a host:

===[/etc/virt-who.d/rhvh.example.com.conf]===
[rhvh.example.com]
type=vdsm
hypervisor_id=hostname
===[end]===

Idea:
Maybe the lack of a "server=rhvh.example.com" directive in there causes virt-who to automatically use its own IP address instead of hostname when communicating with its local vdsm?

Comment 6 Frank Toth 2018-04-13 13:03:04 UTC
Hi,

It's the new jsonrpc connectivity function which causing the issue. It uses socket.getaddrinfo, from the STOMP lib, which returns with the IP and port of the host.

The /usr/lib/python2.7/site-packages/virtwho/virt/vdsm/stomp.py has it's connect function which calls the socket.getaddrinfo and pass the IP and port to the socket.connect which will use IP for the connectivity instead of host name. socket.connect resolves hostnames with both IP V4 and IP V6 addresses anyway.

This small change in stomp.py simply replaces the IP address to original hostname if the IP resolves the same host name:

175a176,177
> 		if self.host == socket.gethostbyaddr(addr[0])[0]:
> 		   addr = (self.host, addr[1])

It won't break the code if the original call was with IP but it won't work without PTR record.

# rpm -qa virt-who
virt-who-0.19-8.el7_4.noarch

# cat /etc/virt-who.d/test.conf
[test]
type=vdsm
hypervisor_id=hostname

# virt-who -o
2018-04-13 12:49:19,034 INFO: Using configuration "test" ("vdsm" mode)
2018-04-13 12:49:19,034 INFO: Using reporter_id='test.example.com-b47d244a49764f43a32ce8191fa2ce1c'
2018-04-13 12:49:19,182 INFO: Report for config "test" gathered, placing in datastore
2018-04-13 12:49:20,134 INFO: Sending update in guests lists for config "test": 11 guests found

Regards,
Frank

Comment 7 Frank Toth 2018-04-13 14:15:50 UTC
Actually this change in stomp.py is better just to be 100% sure to avoid issues when the original host was an IP address:

175a176,177
> 		if self.host == socket.gethostbyaddr(addr[0])[0] and self.host != addr[0]:
> 		   addr = (self.host, addr[1])

Comment 8 Kevin Howell 2018-04-24 20:05:53 UTC
> Actually this change in stomp.py is better just to be 100% sure to avoid issues when the original host was an IP address

Thanks for digging into this Frank! Actually, I don't think we need to check whether or not the resolved IP matches the hostname or not, since internally M2Crypto is already doing this. We can simply always pass the hostname into self.socket.connect when using M2Crypto. I'll open a PR for this upstream shortly.

Comment 9 Frank Toth 2018-04-25 01:30:00 UTC
I just upgraded a hypervisor to the latest image and the issue is solved. The image has virt-who-0.21.5-1.el7.noarch so it has been fixed at some point.

Comment 10 Tsai Li Ming 2018-05-17 16:48:58 UTC
Having the same error on virt-who-0.21.7-1.el7_5.noarch

# cat virt-who-config-1.conf 
[b06.lab.ltsai.com]
server=b06.lab.ltsai.com
type=vdsm
hypervisor_id=hostname

WrongHost: Peer certificate commonName does not match host, expected 192.168.0.210, got b06.lab.ltsai.com

Comment 11 Fedora Update System 2018-06-11 19:11:21 UTC
virt-who-0.22.2-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e4647711f8

Comment 12 Fedora Update System 2018-06-11 19:11:34 UTC
virt-who-0.22.2-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a5b67a9c2f

Comment 13 Fedora Update System 2018-06-12 13:47:14 UTC
virt-who-0.22.2-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e4647711f8

Comment 14 Fedora Update System 2018-06-12 15:11:56 UTC
virt-who-0.22.2-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a5b67a9c2f

Comment 17 errata-xmlrpc 2018-10-30 10:47:49 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-2018:3169


Note You need to log in before you can comment on or make changes to this bug.