Bug 976671

Summary: Recreate trust store when upgrading
Product: Red Hat Enterprise Virtualization Manager Reporter: Alon Bar-Lev <alonbl>
Component: ovirt-engine-setupAssignee: Alon Bar-Lev <alonbl>
Status: CLOSED ERRATA QA Contact: Pavel Stehlik <pstehlik>
Severity: urgent Docs Contact:
Priority: urgent    
Version: unspecifiedCC: acathrow, adahms, alonbl, bazulay, hchiramm, iheim, jkt, lyarwood, mgoldboi, npatil, Rhev-m-bugs, sputhenp
Target Milestone: ---Keywords: ZStream
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: integration
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.
 Story Points: ---
Clone Of:
: 977713 (view as bug list) Environment:
Last Closed: 2014-01-21 17:32:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 977713    

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>
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>
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