Bug 1013946 - [BUG] Custom SSL keystore file not migrated during upgrade to RHEV 3.1
[BUG] Custom SSL keystore file not migrated during upgrade to RHEV 3.1
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup (Show other bugs)
3.1.5
Unspecified Unspecified
high Severity high
: ---
: 3.3.0
Assigned To: Ofer Schreiber
Pavel Stehlik
integration
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-01 02:07 EDT by Bryan Yount
Modified: 2013-10-16 16:43 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-15 02:36:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 501573 None None None Never

  None (edit)
Description Bryan Yount 2013-10-01 02:07:21 EDT
Description of problem:
When RHEV 3.0 is upgraded to 3.1, if a custom SSL keystore is enabled, this keystore is not automatically migrated into the 3.1 environment.

Version-Release number of selected component (if applicable):
rhevm-3.1.0-55
rhevm-setup-3.1.0-55

How reproducible:
Very

Steps to Reproduce:
1. Enable a custom SSL keystore as per the instructions in this kbase article: https://access.redhat.com/site/articles/216903
2. Upgrade to RHEV 3.1
3. Browse to the HTTPS AdminPortal or UserPortal on a fresh web browser where the invalid self-signed certificate was not previously bypassed.

Actual results:
The HTTPS page displays an invalid certificate error

Expected results:
The HTTPS page should display without error

Additional info:
* The name.keystore is found in /etc/pki/rhevm-old/ and it should be copied to /etc/pki/ovirt-engine/
* It should also be chowned ovirt:ovirt
* And added to /usr/share/ovirt-engine/service/engine-service.xml.in
Comment 2 Alon Bar-Lev 2013-10-01 04:44:00 EDT
Custom (manual changed) is not expected to be migrated by product.

Customization of product which is not part of documented and supported interface should be done again.

Please note that overriding files outside of /etc result in losing that customization anyway when rpm is updated, even between rhevm-3.0->rhevm-3.0.
Comment 3 Bryan Yount 2013-10-01 16:33:35 EDT
(In reply to Alon Bar-Lev from comment #2)
> Custom (manual changed) is not expected to be migrated by product.
> 
> Customization of product which is not part of documented and supported
> interface should be done again.
> 
> Please note that overriding files outside of /etc result in losing that
> customization anyway when rpm is updated, even between rhevm-3.0->rhevm-3.0.

It is documented in a tech brief article on our website, therefore it's supported. If that's not the case, we need to pull the tech brief.

I understand that configuration files outside of /etc aren't really safe, however, the keystore file is in /etc/pki. This is a feature that needs to be taken into account with our enterprise customer base. Using a Verisign certificate should be a feature of the product so that users' web browsers will not complain about the self-signed certificate.
Comment 4 Itamar Heim 2013-10-05 14:52:43 EDT
Its an issue for previous versions.
alon - worth clarifying what's the right thing for 3.3 onwards.
for external access (webadmin/user portal)
and for the managed hosts
Comment 5 Alon Bar-Lev 2013-10-05 15:10:06 EDT
(In reply to Itamar Heim from comment #4)
> Its an issue for previous versions.
> alon - worth clarifying what's the right thing for 3.3 onwards.
> for external access (webadmin/user portal)
> and for the managed hosts

external access: already documented (bug#809095)[1].
managed hosts: 3rd party certificate is not supported.

[1] http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3.2/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
Comment 6 Bryan Yount 2013-10-08 21:06:02 EDT
(In reply to Alon Bar-Lev from comment #5)
> (In reply to Itamar Heim from comment #4)
> > Its an issue for previous versions.
> > alon - worth clarifying what's the right thing for 3.3 onwards.
> > for external access (webadmin/user portal)
> > and for the managed hosts
> 
> external access: already documented (bug#809095)[1].
> managed hosts: 3rd party certificate is not supported.

Understood about managed hosts not being supported; that is still the default self-signed cert. And for external access, I realize this is documented for 3.2 but that assumes that you are using Apache for your web portals (port 80). But if you've upgraded from RHEV 3.0 initially, you are still using JBoss for the web portals (port 8080). This scenario is not handled by the rhevm-setup scripts for 3.2 and a separate Bug 1016931 has been opened for this issue.
Comment 7 Alon Bar-Lev 2013-10-09 02:40:29 EDT
(In reply to Bryan Yount from comment #6)
> But if you've upgraded from RHEV 3.0 initially, you are
> still using JBoss for the web portals (port 8080).

If you upgrade from configuration without apache you can in addition overwrite the /etc/pki/ovirt-engine/keys/jboss.p12, this certificate is the certificate used for the jboss SSL, similar to apache.p12(and friends) that are used by apache.
Comment 8 Bryan Yount 2013-10-14 19:56:35 EDT
Alon, this BZ was opened only to address upgrading from 3.0 to 3.1 with a custom SSL keystore. I opened Bug 1016931 to deal with 3.1 to 3.2. So, if upgrading to 3.1 with a custom keystore is not supported, then we can CLOSE WONTFIX this bug I guess?
Comment 9 Alon Bar-Lev 2013-10-15 02:36:41 EDT
(In reply to Bryan Yount from comment #8)
> Alon, this BZ was opened only to address upgrading from 3.0 to 3.1 with a
> custom SSL keystore. I opened Bug 1016931 to deal with 3.1 to 3.2. So, if
> upgrading to 3.1 with a custom keystore is not supported, then we can CLOSE
> WONTFIX this bug I guess?

Yes. I try to avoid closing bugs as WONTFIX unless reporter or PM agree.

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