Description of problem: Certificates generated using the internal CA have a validity of 5 years. This is no longer accepted by many modern browsers. The certificates should be generated with a duration of less than 825 days. Version-Release number of selected component (if applicable): 4.3.9.4-11 How reproducible: Always Steps to Reproduce: 1. Install RHHI latest 2. Check the certificates used by the console 3. Check the certificate use by the imageio deamon. Actual results: Certificates expire in 5 years Expected results: Certificates should expire in max 825 days. Additional info: I actually stumbled upon this when testing the openshift installer against RHHI. The installer was unable to upload disk images. When I investigated this closer I noticed that it had issues connecting to the imagio deamon on the RHVH host. This happened on both Linux and MacOS I was doing this on a Macbook, with MacOS Catalina. I had imported that engine's CA certificate as follows: sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.pem But testing the certificates used by the hosted engine, and by the imagio deamon still yielded a "Certificate not standards compliant" error on the Mac. The reason is that since Catalina MacOS no longer accepts certificates with a lifespan longer than 825 Since this is an official recommendation of the CA/Browser forum I suspect that more and more browsers and SSL/TLS implementations will simple (and silently) refuse to connect with RHHI/RHEV if we do not change this. I found two places where the lifspan is hard coded in scripts: /usr/share/ovirt-engine/bin/pki-enroll-openssh-cert.sh /usr/share/ovirt-engine/bin/pki-enroll-request.sh It is there set to 1800 and should be set to 824. There may be other places that I have not found. I edit those scripts myself, set DAYS to 800 and regenerated the apache.cer on the engine, and /etc/pki/vdsm/certs/vdmscert.pem on the RHV-H hosts. Once I had don that I could connect to the hosted engine using safari and upload images. The openshift installer also now started working, and this both when run from the Mac as well as Linux.
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/
Updating bug title according to comment 6
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.