Bug 1576704 - [RFE] Test oVirt with a 3rd-party CA
Summary: [RFE] Test oVirt with a 3rd-party CA
Keywords:
Status: NEW
Alias: None
Product: ovirt-distribution
Classification: oVirt
Component: General
Version: 4.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
low vote
Target Milestone: ovirt-4.5.0
: ---
Assignee: Yedidyah Bar David
QA Contact: Lukas Svaty
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-10 08:42 UTC by Yedidyah Bar David
Modified: 2019-11-11 13:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Integration
sbonazzo: ovirt-4.5?


Attachments (Terms of Use)

Description Yedidyah Bar David 2018-05-10 08:42:00 UTC
Description of problem:

We should routinely test all components using a 3rd-party CA.

1. Create a CA

Can be using openssl on the lago host, or on the engine machine in a separate directory somewhere, or on a separate VM, or using dogtag, or whatever.

2. Setup an engine

3. Replace all relevant certs there, including:

apache httpd
websocket-proxy
imageio-proxy

See also:

https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/
https://bugzilla.redhat.com/show_bug.cgi?id=1385617
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl#Replacing_the_Manager_SSL_Certificate

4. Verify that these components work well:

- Use wget/curl with the 3rd-party CA cert to connect to httpd and verify the connection

- No idea how to specifically test the imageio/websocket-proxy UI, but we should

Comment 1 Yaniv Kaul 2018-05-13 09:47:03 UTC
The challenge I see here:
1. We do not want to test this as the default - this is NOT what most customers and users use.
2. We do not want to use another suite just for this.


I wonder if could do it as one of the very last tests in the system: do the replacement and then test it.
Since we restart Engine anyway as part of the LDAP tests, I wonder if we should do the modifications then.
Of course, testing the functionality is indeed working is an extra step (we could probably download an image for imageio, the API we today login insecurely, the webui is not tested yet, etc...)

BTW, this is exactly the kind of more 'sophisticated' tests maybe QE should perform?

Comment 2 Yedidyah Bar David 2018-05-14 07:23:53 UTC
(In reply to Yaniv Kaul from comment #1)
> The challenge I see here:
> 1. We do not want to test this as the default -

You mean, "we do want to test the default, which is to use the engine-internal CA for everything"? Agreed.

> this is NOT what most
> customers and users use.

I tend to guess most of the larger setups do use 3rd-party (internal or external) CAs.

> 2. We do not want to use another suite just for this.

Well, not sure, but this is a technical detail - let's first decide what we want. IMO we want (at least?) something like:

1. Install and setup an engine and use default (internal CA for everything)
2. Do some representative sample of operations with it
3. Configure stuff to use a 3rd-party CA
4. Do some representative sample of operations

(2.) can probably be rather small, as I assume that setups that do decide to use 3rd-party CAs, do this early.

(4.) should be rather large - not sure all of current basic-suite, but I rather spend a few more cycles than skip something relevant we didn't think about.

> 
> 
> I wonder if could do it as one of the very last tests in the system: do the
> replacement and then test it.
> Since we restart Engine anyway as part of the LDAP tests, I wonder if we
> should do the modifications then.
> Of course, testing the functionality is indeed working is an extra step (we
> could probably download an image for imageio, the API we today login
> insecurely, the webui is not tested yet, etc...)

That's (4.) above.

Comment 3 Raz Tamir 2018-05-15 12:46:50 UTC
We will have these capabilities in the future as part of our testing coverage


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