Bug 976671 - Recreate trust store when upgrading
Recreate trust store when upgrading
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup (Show other bugs)
unspecified
Unspecified Unspecified
urgent Severity urgent
: ---
: 3.3.0
Assigned To: Alon Bar-Lev
Pavel Stehlik
integration
: ZStream
Depends On:
Blocks: 977713
  Show dependency treegraph
 
Reported: 2013-06-21 03:27 EDT by Alon Bar-Lev
Modified: 2015-09-22 09 EDT (History)
12 users (show)

See Also:
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 12:32:04 EST
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) 405453 None None None Never
oVirt gerrit 13419 None None None Never
oVirt gerrit 16011 None None None Never

  None (edit)
Description Alon Bar-Lev 2013-06-21 03:27:58 EDT
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 03:41:57 EDT
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 03:58:49 EDT
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 06:18:12 EDT
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-27 19:17:58 EST
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 12:32:04 EST
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.