Bug 1824103
| Summary: | Lifespan of certificates created by oVirt engine CA should not exceed 398 days | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Krist van Besien <kvanbesi> |
| Component: | PKI | Assignee: | Dana <delfassy> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Petr Matyáš <pmatyas> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | future | CC: | apinnick, bugs, dfodor, didi, gchakkar, michal.skrivanek, mkalinin, mperina |
| Target Milestone: | ovirt-4.4.3 | Flags: | pm-rhel:
ovirt-4.4+
|
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ovirt-engine-4.4.3.8 | Doc Type: | Release Note |
| Doc Text: |
Up until 4.4.3 RHV used below validity lifetime for certificates:
1. CA certificate - 10 years
2. RHV Manager HTTPS certificate - 5 years
3. RHV hypervisors certificates 5 - years
But due recent efforts to reduce certificate lifetime [1][2] we have decided to shorten RHV certificate lifetime to align with those suggestions:
1. CA certificate - 10 years (no change)
2. RHV Manager HTTPS certificate - 398 days
3. RHV hypervisors certificates 398 days
This change doesn't affect existing certificates, it will be applied only on newly created certificates in RHV 4.4.3 and newer.
We have also discussed to shorten RHV CA certificate lifetime, but we have decided not to change the lifetime, because expiring CA certificate requires reenrolling certificates for all hosts, which means that all hosts needs to go to Maintenance status and this is very disruptive operation.
[1] https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/
[2] https://www.thesslstore.com/blog/ssl-certificate-validity-will-be-limited-to-one-year-by-apples-safari-browser/
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-11 06:42:03 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: | |||
|
Description
Krist van Besien
2020-04-15 10:41:08 UTC
Eh, we certainly don’t want to bring down the whole env every 2 years. IIUC this is just Safari....which we can ignore, but more may follow as well as the time could shorten I though that the hosted engine now automatically reviewed the certificates, so the shorter duration should not be an issue. And it is not just safari. It is chrome/brave as well. And I have my suspicion that some SSL/TLS libraries are now enforcing this too. I stumbled on this problem when testing openshift-install against RHEV. It would not work on both of my systems, not from MacOS (which we do officially support) nor from Rhel 7.7. The problem went away on _both_ systems when I had regenerated the certificates used by the hosted engine and the imagio daemon with a shorter lifespan. Every administrator can replace oVirt engine HTTPS certificates with his own certificate signed by his own CA as mentioned in documentation: https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL.html So that way every administrator can workaround this issue. But Krist is correct, this is official recommendation as defined in https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/ so every certification authority should align with this decision. Unless I'm mistaken CA certificates should still be defined longer, this is only about non-CA certificates I followed that guide, but it is incomplete. The imageio daemon on the nodes will continue to use self signed certificates.
How to replace those certificates is not documented. On a node they live in /etc/pki/vdsm, and the certificate will also be present in /etc/pki/ovirt-engine/certs (where you need to look for <nodename>.cer.)
Basically what I did on the engine was:
export name=<nodename>
export subject="$(openssl x509 -in /etc/pki/ovirt-engine/certs/"${name}".cer -noout -subject | sed 's;subject= \(.*\);\1;')"
/usr/share/ovirt-engine/bin/pki-enroll-request.sh --name="${name}" --subject="${subject}" --san=DNS:${name}
I the copied the resulting .cer file on the node, in /etc/pki/vdsm/certs and renamed it to vdsmcert.pem
Once that done uploading images to the cluster worked from Safari as well (previously it only worked from Firefox), but more importantly, openshit-install now was able to upload the coreos image to the cluster, making a IPI install work.
*** Bug 1832210 has been marked as a duplicate of this bug. *** We probably need to reduce it to one year to be "future proof" - see e.g. https://www.thesslstore.com/blog/ssl-certificate-validity-will-be-limited-to-one-year-by-apples-safari-browser/ The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again. Verified on ovirt-engine-4.4.3.8-0.1.el8ev.noarch This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |