
On Mon, Jun 18, 2018 at 9:19 AM, Tomas Jelinek <tjelinek@redhat.com> wrote:
On Mon, Jun 18, 2018 at 8:01 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Jun 17, 2018 at 6:11 PM, John Florian <jflorian@doubledog.org> wrote:
I followed the docs at https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/ and all works well from the usual web portal. Went to test moVirt and ran into a snag. It wants to download the CA using
http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA, I never tried movirt, but the user's guide [1] says it can import user-supplied certs, so you can supply your own CA's cert, no?
correct, you can supply your own certificate, movirt just by default grabs the one which is provided by engine at: http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA
@Ravi: is it correct that after you provide your own CA that the http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA is still pointing to the old one?
Yes - check this:
https://ovirt.org/develop/release-management/features/infra/pki/#services
It does not have a resource "apache-certificate" or anything like that. The assumption is that user that changes httpd's conf to use a 3rd-party CA, is in control of it, not the engine - so the engine can't handle it. This is even if the user followed the documentation, because in principle, the user can do other things - e.g. point SSLCACertificateFile at a different file instead of replacing the content of the existing apache-ca.pem (which defaults to a symlink to ca.pem, which _is_ controlled by the engine (as in "we do not have any documentation about how to replace it, and doing that will break many flows"). Okay, this is what threw me. The docs are written in such a way that I never touch httpd's conf, as if maybe I am not supposed to do that. The docs have me change the target of a symlink and do other swaps and avoids touching the conf, be it intentional or not. I may have inferred too much based on the approach. So my presumption was that the API should/might continue doing what it did before in providing the correct CA certificate. It would be nice if it did, because entering URLs on a
On 2018-06-18 02:46, Yedidyah Bar David wrote: phone is not my idea of fun and the moVirt feature to go fetch this directly is really handy. So, in my case where Puppet is co-managing my Engine, I take it that it would be acceptable for me to manage httpd's ssl.conf file?
Anyway, patches (to either that web page or movirt, or both) are most welcome!
Best regards,
[1] https://github.com/oVirt/moVirt/wiki/User%27s-guide
but that's grabbing the old CA issued by the engine rather than my custom CA. What else needs to be changed? I'm sure I can finagle my way to a fix here by telling moVirt to use a custom URL or file, but this looks like a bug in the docs that would probably best be fixed.
-- John Florian
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/2DUNW4Y24HW4S5...
-- Didi _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/EXKTGCRWIYIGLW...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/BP74SDAVQNA7IJ...