Bug 1459569 - RHV provider does not trust certificate authorities from the system CA database
Summary: RHV provider does not trust certificate authorities from the system CA database
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.8.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: 5.9.0
Assignee: Juan Hernández
QA Contact: Angelina Vasileva
URL:
Whiteboard: rhev
Depends On:
Blocks: 1478560
TreeView+ depends on / blocked
 
Reported: 2017-06-07 13:25 UTC by Ilanit Stein
Modified: 2019-06-06 11:17 UTC (History)
7 users (show)

Fixed In Version: 5.9.0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1478560 (view as bug list)
Environment:
Last Closed: 2018-03-06 15:22:40 UTC
Category: Bug
Cloudforms Team: RHEVM
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
evm.log (711.16 KB, application/x-gzip)
2017-06-07 13:32 UTC, Ilanit Stein
no flags Details

Description Ilanit Stein 2017-06-07 13:25:55 UTC
Description of problem:
Add RHV provider with 'Verify TLS Certificates' ON,
The 'Trusted CA Certificates' is not taken from CFME, though it is saved there.

Version-Release number of selected component (if applicable):
CFME-5.8.0.17/RHV-4.1.3.1, RHV-4.0.7.4

How reproducible:

Steps to Reproduce:
On CFME, as root user: 
1. scp root@<engine fqdn>:/etc/pki/ovirt-engine/ca.pem /etc/pki/ca-trust/source/anchors/<engine fqdn>.ca.crt

2. update-ca-trust

3. Add RHV provider with 'Verify TLS Certificates' ON, but leave the 'Trusted CA Certificates' empty.

4. Press on 'Validate' button

Actual results:
Validation fail with error in UI (See attached "validate_error" screenshot).

Expected results:
Provider validation should succeed.
Certificate should be taken from the one saved on CFME machine.

Additional info:
If pasting the content of <engine fqdn>:/etc/pki/ovirt-engine/ca.pem in UI 'Trusted CA Certificates' field, Provider Validation is successful.

** This is blocking CFME/RHV provider automation tests from running with TLS ON.

Comment 3 Ilanit Stein 2017-06-07 13:32:34 UTC
Created attachment 1285799 [details]
evm.log

Look for ERROR from the bottom of the log.

Comment 4 Dave Johnson 2017-07-14 03:46:29 UTC
Please assess the importance of this issue and update the priority accordingly.  Somewhere it was missed in the bug triage process.  Please refer to https://bugzilla.redhat.com/page.cgi?id=fields.html#priority for a reminder on each priority's definition.

If it's something like a tracker bug where it doesn't matter, please set it to Low/Low.

Comment 5 Juan Hernández 2017-07-17 08:24:19 UTC
Note that the issue is that the RHV provider doesn't trust the certificate authorities that are registered in the system certificate database, it only trusts the certificate authorities provided explicitly in the form used to add the provider. If nothing is provided in that form, then the provider doesn't trust anything. So the provider is actually more strict than it should. Most RHV installations use a self-signed certificate authority, so this isn't a big issue because it is easier (for the CFME admin) to paste that self-signed certificate in the form than to add it to the system certificate database. For this reason I am lowering the severity.

Comment 6 Juan Hernández 2017-07-17 12:35:32 UTC
This issue is addressed by the following pull request:

  Use nil ca_certs to trust system CAs
  https://github.com/ManageIQ/manageiq-providers-ovirt/pull/63

See the description of that pull request for information about how to verify the issue.

In particular note that the library used by the 'ovirt-engine-sdk' gem doesn't reload the system CA database. That means that in order to test this using version 4 of the RHV API the CFME appliance needs to be restarted after adding the RHV CA certificate to the system CA database.

Comment 8 Radim Hrazdil 2017-11-02 13:57:23 UTC
Verified that after following Steps to Reproduce, provider verification succeeds.

CFME 5.0.9.2, RHV 4.1.3


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