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