Bug 1057673

Summary:	[RFE] Perform preliminary check on certificate-key pairs when doing upgrades and setup
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Tomas Dosek <tdosek>
Component:	ovirt-engine-setup	Assignee:	Alon Bar-Lev <alonbl>
Status:	CLOSED WONTFIX	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.3.0	CC:	acathrow, alonbl, bazulay, gklein, iheim, pablo.iranzo, Rhev-m-bugs, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	integration
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-17 16:08:32 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:	1020228

Description Tomas Dosek 2014-01-24 15:21:49 UTC

Description of problem:
Under certain circumstances it can happen that apache p12 key does not match
the certificate apache-ca.pm.

This is request for feature of setup that would actually check that key-certficate pair is correct and can't cause an outage of service after upgrade

Version-Release number of selected component (if applicable):
is32.2

How reproducible:
100%

Steps to Reproduce:
1. have 3.2 environment
2. corrupt purpusedly /etc/pki/ovirt-engine/apache.p12
3. perform upgrade

Actual results:
upgrade succeeds, httpd service will not start

Expected results:
If the corruption is detected we should either warn the user or warn them
and generate new certificate-key pair.

Comment 1 Alon Bar-Lev 2014-01-24 15:38:17 UTC

Per my previous comment, admins can put key/certificate and skip the PKCS#12 wrapping, so it is incorrect to back-compare it.

The root cause of this issue is manual leftover/invalid state of pki artifacts, unsure it worth to be handled automatically.

Comment 2 Alon Bar-Lev 2014-03-17 16:08:32 UTC

I am closing this for now as unlikely we do this. If we get more reports for this issue, we reopen it as it is no longer local configuration problem.