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.
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.
ovirt does not use PKI correctly, see, 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.
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?
(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
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.
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.
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.
same as BZ1258585 (rhevm-22.214.171.124-0.1.el6.noarch)
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.