Bug 976671 - Recreate trust store when upgrading
Summary: Recreate trust store when upgrading
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup
Version: unspecified
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 3.3.0
Assignee: Alon Bar-Lev
QA Contact: Pavel Stehlik
URL:
Whiteboard: integration
Depends On:
Blocks: 977713
TreeView+ depends on / blocked
 
Reported: 2013-06-21 07:27 UTC by Alon Bar-Lev
Modified: 2018-12-01 14:24 UTC (History)
12 users (show)

Fixed In Version: is6
Doc Type: Bug Fix
Doc Text:
Previously, migrating from Red Hat Enterprise Virtualization version 2.2 to 3.0 would update the key store with the CA certificate and not the trust store, resulting in an unusable trust store when later upgrading to Red Hat Enterprise Virtualization version 3.2. With this update, the trust store is now re-created during the upgrade to Red Hat Enterprise Virtualization 3.2, resulting in a valid trust store.
Clone Of:
: 977713 (view as bug list)
Environment:
Last Closed: 2014-01-21 17:32:04 UTC
oVirt Team: ---
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 405453 0 None None None Never
Red Hat Product Errata RHSA-2014:0038 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.3.0 update 2014-01-21 22:03:06 UTC
oVirt gerrit 13419 0 None None None Never
oVirt gerrit 16011 0 None None None Never

Description Alon Bar-Lev 2013-06-21 07:27:58 UTC
There are cases in which CA certificate was re-issued but the trust store was not updated.

Known use cases: bug#824056.

This lead to failure of ovirt-engine-3.2.0 communicating with vdsm.

We probably can assume that /etc/pki/ovirt-engine/ca.pem is updated and recreated the trust store when upgrading.

WORKAROUND

# cp /etc/pki/ovirt-engine/.truststore /etc/pki/ovirt-engine/.truststore.$(date +%Y%m%d%H%M%S)
# keytool -delete -noprompt -alias cacert -keystore /etc/pki/ovirt-engine/.truststore -storepass mypass
# keytool -import -noprompt -trustcacerts -alias cacert -keypass mypass -file /etc/pki/ovirt-engine/ca.pem -keystore /etc/pki/ovirt-engine/.truststore -storepass mypass

Comment 1 Alon Bar-Lev 2013-06-21 07:41:57 UTC
Re-running setup did not re-created the keystore if already existed, this was already found and resolved in 3.3.

---

commit 79fd22cc88abbb24a64b9d9e607d6440e56cdace
Author: Alon Bar-Lev <alonbl@redhat.com>
Date:   Fri Mar 29 01:15:47 2013 +0200

    pki: delete cacert alias from keystore before import
    
    Java keystore will not overwrite certificate, leaving the previous one.
    
    Change-Id: Ib0ea2404ff43c106f40ddc89cf13cb2b8d7caeab
    Signed-off-by: Alon Bar-Lev <alonbl@redhat.com>

Comment 2 Alon Bar-Lev 2013-06-21 07:58:49 UTC
BTW: This issue (comment#1) was discovered when the new devenv was reinstalled to same directory. The root cause is a lack of check for failure in the pki scripts. Because of that and other issues in code, and because bug#824056, I completely re-wrote[1] the pki scripts to higher level of shell programming, and to be human usable. And even this is not enough as I had to leave the files' format, location and permissions that should also be modified.

[1] http://gerrit.ovirt.org/#/c/15499/

Comment 3 Alon Bar-Lev 2013-06-21 10:18:12 UTC
An update, thanks to Lee Yarwood for the references.

rhevm migration tool from 2.2 to 3.0 updated the .keystore[1] and not the .truststore with the ca certificate.
rhevm-3.0 had issue it adds .keystore[1] and not .truststore[2] to the database, while creating .truststore[4].
rhevm-3.1 behaves in similar manner.
rhevm-3.2 is using the .truststore, so if the .keystore was updated by the migration tool we end up with invalid .truststore.

The solution outlined at comment#0 is valid and can be run automatically at upgrade to 3.2 to solve this as well.

[1] http://git.engineering.redhat.com/?p=users/jhernand/migration_tool_etl.git;a=blob;f=rhevm-migration-linux.py;hb=master#l1976
[2] http://git.engineering.redhat.com/?p=users/dfediuck/rhevm.git;a=blob;f=packaging/rhevm-setup.py;hb=HEAD#l1233
[3] http://git.engineering.redhat.com/?p=users/dfediuck/rhevm.git;a=blob;f=packaging/rhevm-setup.py;hb=HEAD#l996
[4] http://git.engineering.redhat.com/?p=users/dfediuck/rhevm.git;a=blob;f=backend/manager/conf/ca/installCA.sh;hb=HEAD#l95

Comment 13 Charlie 2013-11-28 00:17:58 UTC
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Comment 14 errata-xmlrpc 2014-01-21 17:32:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2014-0038.html


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