Project

General

Profile

Bug #7516

Ovirt compute resource doesn't work with wildcard certs

Added by Dominic Cleal about 5 years ago. Updated almost 5 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Compute resources - oVirt
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1119420
Description of problem:

When configuring Satellite 6 beta with a ovirt/rhevm compute resource that is using a wildcard cert for HTTPS, the user is presented with the following error:

"'ERF56-1309 [Foreman::FingerprintException]: The remote system presented a public key signed by an unidentified certificate authority. If you are sure the remote system is authentic, go to the compute resource edit page, press the 'Test Connection' or 'Load Datacenters' button and submit'"

The message is repeated each time the user clicks 'submit' and is thus unable to create the compute resource

Version-Release number of selected component (if applicable):
foreman-ovirt-1.6.0.21-1.el6sat.noarch
ruby193-rubygem-rbovirt-0.0.26-2.el6sat.noarch

How reproducible:
100%

Steps to Reproduce:
1. Configure RHEV-M to use a 3rd party cert, such as per (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html-single/Administration_Guide/index.html#Replacing_the_SSL_certificate_used_by_Red_Hat_Enterprise_Virtualization_Manager_to_identify_itself_to_users_connecting_over_https)
2. attempt to Configure Sat6 to use an ovirt resource
3.

Actual results:
User is unable to successfully configure an ovirt compute resource

Expected results:
User is able to successfully configure an ovirt compute resource

Additional info:


Related issues

Related to Foreman - Bug #7522: RHEV/oVirt compute resource should have CA text field editableClosed2014-09-18

History

#1 Updated by Dominic Cleal about 5 years ago

  • Category set to Compute resources - oVirt
  • Assignee deleted (Lukas Zapletal)

Is this because /ca.crt isn't updated? Or is it because we can't validate the entire CA chain as we only have the end cert?

#2 Updated by Lukas Zapletal about 5 years ago

This is because ca.crt does point to the server certificate, instead of CA. For self-signed cert this is okay, once you have separate CA (which is expected on production systems, here the case is wild-card), then there is no way to change that on oVirt/RHEV side as it's "hardcoded" in the codebase.

I asked RHEV devs to allow some nice change of CA but it looks like this was marked as doco only: https://bugzilla.redhat.com/show_bug.cgi?id=1125933

WORKAROUND: Put your proper CA file to /var/www/htdocs and remove the proxy for the /ca.crt url:

  cp your_ca.crt /var/www/html/ca.crt
   (optionally relabel the file)
  sed -iE 's/ca.crt$|//' /etc/httpd/conf.d/z-ovirt-engine-proxy.conf

I think we should consider to allow users to input their CA into the field manually. I don't know why do we prevent that at all. Fetching the /ca.crt is not what is expected from RHEV side as they describe this "for testing purposes only".

#3 Updated by Ohad Levy about 5 years ago

Lukas Zapletal wrote:

I think we should consider to allow users to input their CA into the field manually. I don't know why do we prevent that at all. Fetching the /ca.crt is not what is expected from RHEV side as they describe this "for testing purposes only".

AFAIR we discussed this already and agreed to allow it?

#4 Updated by Dominic Cleal about 5 years ago

  • Related to Bug #7522: RHEV/oVirt compute resource should have CA text field editable added

#5 Updated by Lukas Zapletal about 5 years ago

Yes, I filed another issue/BZ for this because I am not 100% sure if the wildcard issue is another one or it will be solve by that: http://projects.theforeman.org/issues/7522

I will fix this today as it's a easy fix and this one is annoying.

#6 Updated by Lukas Zapletal almost 5 years ago

  • Status changed from New to Rejected

I can confirm. Wildcard certs are not the issue. Once I was able to deploy the correct cert chain in the editable field, it worked like charm. Closing this one.

Also available in: Atom PDF