Hi, It looks like step 5 has been left out of the D2 Instructions. From comment c#20: 5. Copy the certificate to its expected location. # cp /tmp/apache.cer /etc/pki/ovirt-engine/certs/apache.cer I can't see this anywhere in the current docs. If I search for 'apache.cer', I can't when the actual cert is copied into place. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1416232#c20 [2] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl
Hi Didi, I've got a couple of additional questions: 1. Are the steps the same in 4.0 and 4.1? If there's no difference, it'll be easy to update the 4.0 docs as well (I forgot to suggest this in BZ#1416232). 2. Marcus also pointed out, when we talked on IRC, that in step 1 of procedure D2 we use "cp /tmp/<3rd-party-ca-cert>.pem /etc/pki/ca-trust/source/anchors" before "update-ca-trust", whereas this solution[1] uses "trust anchor /<path>/ca.crt" before "update-ca-trust". IIUC, "cp /tmp/<3rd-party-ca-cert>.pem /etc/pki/ca-trust/source/anchors" and "trust anchor /<path>/ca.crt" do basically the same thing, just with a different command. Can you confirm whether this is the case? Is one of these commands preferred over the other? [1] https://access.redhat.com/solutions/2610251
(In reply to Tahlia Richardson from comment #1) > Hi Didi, > > I've got a couple of additional questions: > > 1. Are the steps the same in 4.0 and 4.1? If there's no difference, it'll be > easy to update the 4.0 docs as well (I forgot to suggest this in BZ#1416232). Yes, they are the same. Much of it applies the same to 3.6 as well. ENGINE_HTTPS_PKI_TRUST_STORE was added in 4.0.1.1, bug 1336838. > > 2. Marcus also pointed out, when we talked on IRC, that in step 1 of > procedure D2 we use "cp /tmp/<3rd-party-ca-cert>.pem > /etc/pki/ca-trust/source/anchors" before "update-ca-trust", whereas this > solution[1] uses "trust anchor /<path>/ca.crt" before "update-ca-trust". > IIUC, "cp /tmp/<3rd-party-ca-cert>.pem /etc/pki/ca-trust/source/anchors" and > "trust anchor /<path>/ca.crt" do basically the same thing, just with a > different command. Can you confirm whether this is the case? Is one of these > commands preferred over the other? It seems they do the same thing. 'trust anchor' only exists in RHEL7, not 6. So I assume that docs that were written in -6 days kept the older command (which works on both). Not sure which is preferred. Searched a bit and found some relevant stuff, including: https://fedoraproject.org/wiki/Features/SharedSystemCertificates Setting needinfo on Kai, with the hope he can give us some insights, pointers, etc. > > > [1] https://access.redhat.com/solutions/2610251
Adding Daiki, who maintains p11-kit-trust, which provides the trust command, in case he wants to give additional thoughts. The approach to copy a file manually into the /etc/pki/ca-trust/source/anchors is still supported. See also the man page for update-ca-trust, which explains the purpose of the various directories involved. The trust command is an alternative way of installing. I cannot give a clear advice on which approach is preferred. However, it's known that by using the trust command, certain CAs can be installed, which would otherwise be ignored because of their properties.
*** Bug 1481249 has been marked as a duplicate of this bug. ***
No response from the additional needinfo yet, so for now I'll just add the missing step and backport to 4.0, since the trust anchor step does work as is (perhaps we'll change it from the cp command to the trust command in future). (In reply to Kai Engert (:kaie) from comment #3) > The trust command is an alternative way of installing. I cannot give a clear > advice on which approach is preferred. However, it's known that by using the > trust command, certain CAs can be installed, which would otherwise be > ignored because of their properties. To clarify, is this a good thing or a bad thing in this context? I.e. is it good that additional CAs can be installed that couldn't with the cp command, or were those certain CAs ignored on purpose for reasons (making it bad that the trust command can install them)?
(In reply to Tahlia Richardson from comment #5) > > To clarify, is this a good thing or a bad thing in this context? I.e. is it > good that additional CAs can be installed that couldn't with the cp command, > or were those certain CAs ignored on purpose for reasons (making it bad that > the trust command can install them)? It's good for the user, because if a CA couldn't be added with the cp command, but it works with the trust command, then it probably was a bug that it couldn't be added with the cp command.
(In reply to Kai Engert (:kaie) from comment #7) > (In reply to Tahlia Richardson from comment #5) > > > > To clarify, is this a good thing or a bad thing in this context? I.e. is it > > good that additional CAs can be installed that couldn't with the cp command, > > or were those certain CAs ignored on purpose for reasons (making it bad that > > the trust command can install them)? > > It's good for the user, because if a CA couldn't be added with the cp > command, but it works with the trust command, then it probably was a bug > that it couldn't be added with the cp command. Thanks Kai, sounds like changing it is a good idea, then.
Now published at https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl#Replacing_the_Manager_SSL_Certificate and https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl#Replacing_the_Manager_SSL_Certificate