Bug 1336873 - [RFE] Provide Ansible-based tool to replace web SSL certificate generated by internal oVirt CA with 3rd party certificate provided by administrator
Summary: [RFE] Provide Ansible-based tool to replace web SSL certificate generated by ...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Setup.Engine
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Yedidyah Bar David
QA Contact: Petr Kubica
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-17 16:36 UTC by David Jaša
Modified: 2020-06-26 16:38 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-04-01 14:48:18 UTC
oVirt Team: Integration
Embargoed:
pm-rhel: ovirt-4.5?
jbelka: testing_plan_complete-
ylavi: planning_ack?
ylavi: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

Description David Jaša 2016-05-17 16:36:24 UTC
Description of problem:
Ovirt's 4.0 authentication framework makes connections to itself over https. This fact adds a new requirement on https setup on engine: the web certificate must be verified as trusted so engine-setup should validate if http service SSL configuration works OK. This might be difficult to do by looking into server configuration (there are at least three TLS modules for apache/httpd, there are other HTTP servers around, the HTTP server might run on different machine) but if we make assumptions that:

1) SSL is configured on the web server
2) http server is running before engine-setup runs
3) engine-setup is given FQDN early in the process
4) java and python trust the same certificates for 3 years already [1]

then engine-setup can verify certificate presence in black-boxy way: just do HTTP get on https://fqdn/ [2]. When this HTTP GET passes, engine-setup knows that engine will trust connection to itself so SSO will work, if not, admin can be warned of problems in advance.

[1] https://fedoraproject.org/wiki/Features/SharedSystemCertificates
[2] on RHEL 7: verification must be turned on explicitly


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

How reproducible:
always

Steps to Reproduce:
1. configure mod_ssl to use certificate issued by CA unknown to system
2. run engine-setup with Apache SSL set to Manual
3. log in as admin@internal

Actual results:
(both in engine.log and web UI after logging form)
server_error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Expected results:
engine-setup will warn admin about incorrect SSO configuration (or unreachable web server) during step 2


Additional info:
can't be tested until bug 1336838 gets fixed

--------------------------------------------

server name validation in 2.7 can be turned on e.g. this way:
import urllib2, ssl
ctx = ssl.create_default_context()
url = ''.join('https://', fqdn, '/')
try:
    urllib2.urlopen(url, context = ctx)
except ssl.CertificateError, urllib2.URLError:
    # web server not running or with wrong certificate ...

Comment 1 Martin Perina 2016-05-27 19:28:13 UTC
Manual steps to configure custom HTTPS certificate are described in BZ1336838, I think that this one should be changed to RFE for 4.1

Comment 2 Red Hat Bugzilla Rules Engine 2017-02-06 10:20:19 UTC
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.

Comment 3 Yaniv Kaul 2017-06-06 19:24:25 UTC
Ansible looks like a good solution to me here.

Comment 4 Red Hat Bugzilla Rules Engine 2017-09-26 11:46:55 UTC
Testing has indicated this request is declined. You may appeal this decision by reopening this request.

Comment 5 Sandro Bonazzola 2019-02-18 07:54:58 UTC
Moving to 4.3.2 not being identified as blocker for 4.3.1.

Comment 6 Michal Skrivanek 2020-03-19 15:42:06 UTC
We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it.
If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.

Comment 7 Michal Skrivanek 2020-04-01 14:48:18 UTC
Closing old bug. Please reopen if still relevant/you want to work on it.


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