Title: Replacing the Red Hat Enterprise Virtualization Manager SSL Certificate Describe the issue: In case the certificate has been generated by internal IT authority, certificate files can be provided in various naming conventions. This section is unclear about which files contain what data. For example the first command: mv YOUR-3RD-PARTY-CERT.pem /etc/pki/ovirt-engine/apache-ca.pem It's not clear what the YOUR-3RD-PARTY-CERT.pem file contains. Is this the authority CA cert? Is this the cert issued? With or without appended private key? Suggestions for improvement: In the prerequisite section, I'd appreciate full list (table) of all the input files with descriptions of the content.
*** Bug 1146775 has been marked as a duplicate of this bug. ***
Hi, It might be worthwhile providing a hierarchical map of all of the keys, signing requests and certificates in all of their formats, and the services that use them (for restarting) and any file permissions needed. It would also be good to know what opsnssl.conf settings are needed for each certificate and what constraints are required by the CA for RHEVm This would then be detailed with steps for every one of those components. A few of these components have been documented in kbase articles [1]. In GSS case 01217776 we leaned how to restore apache.cer and apache.key.nopass from a .p12 store [2] This would allow both customers and GSS to determine both how to replace CA certs and all follow on certificates and to repair broken installations. [1] https://access.redhat.com/solutions/405333 https://access.redhat.com/solutions/972613 [2] #openssl pkcs12 -passin "pass: PASSWORD " -nokeys -in /etc/pki/ovirt-engine/keys/apache.p12 > /etc/pki/ovirt-engine/certs/apache.cer # openssl pkcs12 -passin "pass: PASSWORD " -nocerts -nodes -in /etc/pki/ovirt-engine/keys/apache.p12 > /etc/pki/ovirt-engine/keys/apache.key.nopass # chmod 0600 /etc/pki/ovirt-engine/keys/apache.key.nopass Other parts to include are what certificate chains are needed (by clients and other components) where especially where the custom CA cert might a third tier certificate.
If replacing certificates on a established system is at home in the administration guide as opposed to being part of a deployment guide then it is imperative that all of the components for SSL are exposed
Changing status back to 'New' until re-assignment.
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
Closing this as a duplicate of bug 1416232, which tracks multiple feedback back items for this section. *** This bug has been marked as a duplicate of bug 1416232 ***