Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1188759

Summary:	[RFE][PKI] Notify Admin on certificate expiration
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Marina Kalinin <mkalinin>
Component:	RFEs	Assignee:	Moti Asayag <masayag>
Status:	CLOSED ERRATA	QA Contact:	Jiri Belka <jbelka>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.4.4	CC:	amureini, iheim, lbopf, lpeer, lsurette, mkalinin, oourfali, pstehlik, rbalakri, sherold, yeylon, ykaul
Target Milestone:	ovirt-3.6.0-rc	Keywords:	FutureFeature, UserExperience
Target Release:	3.6.0	Flags:	sherold: Triaged+
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	3.6.0-5	Doc Type:	Enhancement
Doc Text:	The Red Hat Enterprise Virtualization Manager now periodically monitors the CA certificate, the Manager certificate, and host certificates, and reports via the event log when a certificate is about to expire. The Manager also produces an alert for hosts when their certificates have expired. A new button in the Hosts tab allows the user to enroll a certificate for the host. The same action is exposed in the REST API, by sending a POST request to '/api/hosts/{host:id}/enrollcertificate'.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-09 20:56:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1214860, 1258585, 1259601
Bug Blocks:	902971

Description Marina Kalinin 2015-02-03 16:11:57 UTC

Description: Notify RHEV Admin on certificate expiration.
Why: there are certificates in RHEV, that once expired, would make the environment unavailable and would require certificate regeneration, unwanted production down time, man power etc.

We should notify RHEV Administrator that the certificates are going to expire and the environment would become unusable in advance, to let the user prepare and schedule upgrade.

How to provide the notification?
I think we should start with one 6 month before expiration; another one 3 month, 2 month and then daily in the last month.
How: both email + alerts. 
Best would give some popup on login and something that would be constantly visible to the admin.

What certificates?
For my understanding it should be CA, RHEV-M cert and Host cert acquired during registration.

Reason for this request:
To make customers upgrading.
Despite multiple requests and notifications from Red Hat side, many customers still choose not to upgrade and then come to GSS with completely broken environment that takes significantly longer time to fix and many man hours.
This warning should help preventing those scenarios.
It would also be logged in the environment as a proof that the customer was notified and didn't act.

Comment 8 Alon Bar-Lev 2015-04-23 17:32:13 UTC

ovirt does not use PKI correctly, see[1], as there is no revocation nor management, a certificate could have been issued for 10000 years. Sane expiration period should be at the most two years.

as PKI is not managed it has no capability of automatic renew.

PKI was the one component I did not write from scratch (except of rewriting the code to make it actually work and usable). There is much work to be done all over the project to support PKI properly.

Due to bug#1210486 we will already renew CA certificate and engine certificate. so we can add this as well to renew CA certificate, engine certificate and apache certificate, I opened bug#1214860. This will not renew all certificates but will provide remedy for an event in which expiration of important certificate expiration. 

[1] http://www.ovirt.org/Features/PKI#Caveats

Comment 9 Marina Kalinin 2015-05-01 18:19:44 UTC

So, if I understand correctly, bug#1214860 should cover all the related certificates renewal.

However, this is not enough of a solution for our case.
What about those certificates that are expiring before the customer is updating to the version that will contain bug#1214860 fix? 
If this bug fix is going to take too long to be implemented, we should implement the warning suggested in this RFE to notify the admin and contact support.

And lastly - ideally would be great to have such a tool, of updating old certificates, in case customers are not willing to upgrade. This is pretty common scenario, especially with big, strategic finance organizations. 
But this part may also be implemented in GSS.

Alon, Oved, comments?

Comment 10 Alon Bar-Lev 2015-05-01 18:26:28 UTC

(In reply to Marina from comment #9)
> So, if I understand correctly, bug#1214860 should cover all the related
> certificates renewal.

ca and engine are the important ones, they will be renewed a year before expiration when running engine-setup.

> However, this is not enough of a solution for our case.
> What about those certificates that are expiring before the customer is
> updating to the version that will contain bug#1214860 fix? 

if no update is done, then no fix [any fix] can be pushed, and you revert to manual procedure.

> If this bug fix is going to take too long to be implemented, we should
> implement the warning suggested in this RFE to notify the admin and contact
> support.

I will work to have this in 3.5.3.

> And lastly - ideally would be great to have such a tool, of updating old
> certificates, in case customers are not willing to upgrade. This is pretty
> common scenario, especially with big, strategic finance organizations. 
> But this part may also be implemented in GSS.

You can grab the pki-* scripts of 3.5.3 (when be ready) and use it in 3.4.z to renew certificates, I will guide you when all is completed in 3.5.z.

Comment 11 Marina Kalinin 2015-05-01 20:05:04 UTC

1. How can we push this to 3.5.3 with more urgency? (However, thinking about that, maybe not that many customers with 3.5 today started their setup before 5 years. So it may still wait till 3.5.4 or some other 3.5.z. However I do not have any statistics.

2. The procedure, I guess, we will work on it per case. Since it is not only 3.4 customers, but all the way starting 3.0 (even 2.2). And I do not believe that 3.4 scripts would work on earlier setups.

Comment 12 Alon Bar-Lev 2015-05-05 12:02:26 UTC

ca and engine certificates will be renewed if invalid or if will expire in one year. this went to ovirt-enigne-3.5.3.

notice that at least firefox requires the renewed CA to be distributed with enterprise, otherwise it prints a warning message requiring to reapprove certificate.

it is not about notification but actual renew, so I keeping this bug opened.

for pre-3.5 you should be able to use the pki-* scripts of 3.5.3, copy them to temporary location and execute as follows:

# ./pki-create-ca.sh --renew --keystore-password=mypass
# ./pki-enroll-pkcs12.sh --keep-key --name=engine --password=mypass --subject="/C=X/O=X/CN=X" #### REPLACE X with actual value ####

after renew the hosts should be uninfected and up (providing their certificates is not expired), host-deploy should be used to re-enroll their certificates.

Comment 14 Jiri Belka 2016-01-11 14:05:08 UTC

same as BZ1258585 (rhevm-3.6.1.3-0.1.el6.noarch)

Comment 16 errata-xmlrpc 2016-03-09 20:56:46 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.

https://rhn.redhat.com/errata/RHEA-2016-0376.html