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.
# 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.
Author: Alon Bar-Lev <email@example.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.
Signed-off-by: Alon Bar-Lev <firstname.lastname@example.org>
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 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.
An update, thanks to Lee Yarwood for the references.
rhevm migration tool from 2.2 to 3.0 updated the .keystore and not the .truststore with the ca certificate.
rhevm-3.0 had issue it adds .keystore and not .truststore to the database, while creating .truststore.
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.
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:
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.