On Mon, Jun 18, 2018 at 4:19 PM, John Florian <j...@doubledog.org> wrote: > On 2018-06-18 02:46, Yedidyah Bar David wrote: >> >> On Mon, Jun 18, 2018 at 9:19 AM, Tomas Jelinek <tjeli...@redhat.com> >> wrote: >>> >>> >>> On Mon, Jun 18, 2018 at 8:01 AM, Yedidyah Bar David <d...@redhat.com> >>> wrote: >>>> >>>> On Sun, Jun 17, 2018 at 6:11 PM, John Florian <jflor...@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.
I don't remember every exact detail in the docs, but I do know the relevant code. The engine (itself) runs as user ovirt, and can't touch or do anything to your httpd conf. engine-setup is basically the only thing [1] that runs as root and touches httpd conf. It asks you some stuff, and does (currently) only these things: 1. Always add /etc/httpd/conf.d/z-ovirt-engine-proxy.conf . This file is considered to be "owned" by engine-setup and can be changed as needed by upgrades. So you are not supposed to touch it. 2. Optionally add /etc/httpd/conf.d/ovirt-engine-root-redirect.conf which does a very simple redirect from '/' to '/ovirt-engine'. I am not aware of anyone not doing this, and guess things might not work perfectly, and also that it might be unsupported, but in principle you can reply 'no', and then have other web apps on the engine machine. See also [2]. This is _not_ done on upgrades - so if you reply 'yes', then remove the file, then run 'engine-setup' again, it should not re-add the file. 3. Optionally edit ssl.conf, which is the subject of current thread. This one also used to be not done on upgrades, but this recently changed [3][4]. This is considered mandatory and the only supported flow in production. If you reply 'no', you are supposed to configure apache manually. However, for development, you can talk to jboss directly [5]. This used to be possible also in production in very old releases, see e.g. [6]. So, to summarize: We (engine developers, engine-setup in particular) try to be "good citizens" and not take control of the machine, allowing the admin do what s/he wants, and still try hard to make the engine work nicely. But we default to do "take over", and (IIRC) only document the default, and (IIUC) only test the default - so anything else is somewhat more likely to cause problems. [1] currently. We add lots of ansible stuff in recent releases, I suspect that engine-setup has a chance to be partially replaced with ansible code some time. [2] https://bugzilla.redhat.com/show_bug.cgi?id=961677 [3] https://bugzilla.redhat.com/1558500 [4] https://bugzilla.redhat.com/1576377 [5] https://www.ovirt.org/develop/developer-guide/engine/engine-development-environment/ [6] https://bugzilla.redhat.com/show_bug.cgi?id=905754 > 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 phone is not my idea > of fun and the moVirt feature to go fetch this directly is really handy. Patches (or at least RFEs) are welcome :-) Also note that movirt, IIUC, should get from httpd the entire chain of certs, including the root one (your CA's cert), so in principle can simply prompt you, asking "Do you want to trust this CA cert?". Browsers, at least most of them, at least by default, never do this - they only prompt you asking if you want to trust a specific https cert, and require the user to manually import CA certs (I guess with the assumption that most users should only use the "well known" ones shipped with the browser, and that sysadmins that want an organization-wide CA will add its cert to their clients using other means). But they do let you use the CA cert right from inside the browser - e.g., I now tried this: 1. engine-setup 2. connect with firefox to the machine. Got "insecure", pressed "Advanced", "Add exception", "Get certificate", "View...", "Details" tab, selected the top cert in the hierarchy (which is the engine's CA cert - defaults to $FQDN.$RANDOM_NUMBER), "Export", "Save", closed everything. 3. Then went to the browser's menu, "Edit", "Preferences", "Advanced", "Certificates", "View certificates", "Authorities", "Import", opened the file I saved in (2.), checked "Trust this CA to identify websites", "OK", "OK" 4. Now connect again to the web admin url, it does not say anymore it's an unknown issuer. Nothing prevents firefox, or movirt, from doing all of the above with a single button click. The only reason they don't, and which is a quite good reason, is that it's risky for the user, and they want to make it hard to lower the risk. The flow above, needless to say, has nothing to with oVirt - it's all part of httpd's configuration and the SSL protocol. > > 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? By all means, yes, and if you run into problems, please open bugs. With [3] _and_ [4] above fixed, engine-setup, on upgrades, should only change (currently) SSLProtocol, after asking you, and not override any other option you set there. > > >>>> >>>> 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-le...@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/2DUNW4Y24HW4S5K4VGLIZRVR2K7BF37Z/ >>>>> >>>> >>>> >>>> -- >>>> Didi >>>> _______________________________________________ >>>> Users mailing list -- users@ovirt.org >>>> To unsubscribe send an email to users-le...@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/EXKTGCRWIYIGLWFVMWOHBDLAZCEGIOJG/ >>> >>> >>> >>> _______________________________________________ >>> Users mailing list -- users@ovirt.org >>> To unsubscribe send an email to users-le...@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/BP74SDAVQNA7IJVKAWYHFCNHWOEQYITQ/ >>> >> >> > -- Didi _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/MAUXU4AP7CDBIE6Z5V3SCDJCSRNUD6DM/
