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 1257886 - Need trust anchor thing while using remote-viewer connect to .vv file to see foreign menu
Summary: Need trust anchor thing while using remote-viewer connect to .vv file to see ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virt-viewer
Version: 8.0
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.1
Assignee: Default Assignee for SPICE Bugs
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1682781
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-28 10:23 UTC by zhoujunqin
Modified: 2020-11-14 08:55 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-09 19:05:55 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description zhoujunqin 2015-08-28 10:23:58 UTC 
Description of problem:
Need trust anchor thing whlie using remote-viewer connect to .vv file, otherwise foreign menu cannot be seen.

Version-Release number of selected component (if applicable):

virt-viewer-2.0-6.el7.x86_64
libgovirt-0.3.3-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
Prepare a rhevm3.6 environment and a running guest on it:the guest can only be seen in admin portal.

1. Download guest file "console.vv" to check 'admin' field in the [ovirt] section of .vv files 

1.1 Login rhevm server with rhevm hostname instead of ip, right-click on this guest and select "Console Options" item, then select Console Invocation as "Native client".

1.2. Click the guest and select "Console" item, then save the console file "console.vv" to local machine.

1.3. Open file console.vv check the 'admin' field in the [ovirt] section 
# cat console.vv
...
[ovirt]
host=dell-op780-05.qe.lab.eng.nay.redhat.com
vm-guid=38e8d75c-1825-4c7a-b72d-7c9953fd96f4
jsessionid=xmhCoeXUUSsQbAuE5D0EHg4B
admin=1

2. Use remote-viewer launch guest:
# remote-viewer console.vv 

3. Download ca.crt file and then do "trust anchor ca.crt" as root before testing, then run step1 & step2 again.

# wget -k https://$rhevm-hostname/ca.crt

# trust anchor ca.crt


Actual results:
After step2, without trusting anchor thing, remote-viewer can launch guest but cannot see foreign menu.
After step3, with trusting anchor thing, remote-viewer can launch guest and foreign menu "Change CD" can be seen.

Expected results:
Without trust anchor thing whlie using remote-viewer connect to .vv file, foreign menu can be seen.

Additional info:
Comment 2 David Jaša 2015-08-31 12:00:36 UTC 
This bug a slim chance for good solution so we're probably left with:
- good error message in virt-viewer
- a good documentation explaining what's needed


Let me explain: 
The root cause is RHEV API cert is neither trusted system-wide, nor specified system wide. The issue is complicated however because the certificate used for web can be and frequently is issued by different CA than RHEV CA - and RHEV doesn't have powers to ensure that the CA is even known to RHEV. This is caused by usual CA chain in TLS:

RootCA (trusted) [- intermediateCA_1 [- intermediateCA_n]] - webCertificate

The root CA
- is expected to be included in client system (in ca certificates or among
    trust anchors)
- is not expected to be included in CA chain
So in configuration with no intermediate CAs, the root CA cert may not even be included in RHEV-M system (in case it is some internal CA) so the only thing that engine can supply to the client is the web cert itself.

To make things more complicated, the TLS in RHEV is provided by apache and what RHEV does is merely a default configuration so getting the web certificate in use is not exactly an easy task to solve (well, by default, reading it from ssl.conf should be enough in most setups - but the only reliable way is to connect to apache and read the cert from ServerHello).

On client side, libsoup - glib's http library used for libgovirt networking - would need to support to add RHEV-M cert as trusted one. I have no idea if it has such a capability


If these two issues are resolved in satisfactory way, then it should be possible to add the web certificate to a new item in vv file [ovirt] section and have libgovirt use it. The room for things not working as expected would however still remain large so the question is if it is worth the hassle.
Comment 3 Christophe Fergeau 2015-09-07 14:38:36 UTC 
Current state is that:
- if SPICE CA and web CA are the same, then 'trust anchor' needs to be used
- if SPICE CA and web CA are not the same, then 'trust anchor' needs to be used

The easy fix to #1 so that 'trust anchor' is not needed breaks #2 with no possible workaround, which is not so nice :(
Comment 4 Christophe Fergeau 2016-06-14 16:27:56 UTC 
No good solution in sight for 7.3 I'm afraid, moving to 7.4...
Comment 6 Christophe Fergeau 2018-12-21 12:46:03 UTC 
Looking at this again, librest could detect the invalid CA in _call_message_completed_cb by using soup_message_get_https_status() and then report an error to the upper layer (libgovirt in our case). We could then show some error dialog to the user saying the certificate is invalid, and let it override this. Needs some work in librest first, not el7 material.
Comment 7 Christophe Fergeau 2018-12-21 12:47:06 UTC 
Resetting devel_ack+ as this needs to be prioritized first.
Note You need to log in before you can comment on or make changes to this bug.