On Tue, Jun 19, 2018 at 5:35 PM, John Florian <jflor...@doubledog.org> wrote: > On 2018-06-19 02:57, Yedidyah Bar David wrote: >> 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 > > That is some excellent detail. Thanks for sharing. I've opted to take > a similar "good citizen" approach with my Puppet handling by leaving > ssl.conf as is and just manipulating the symlink and certificate/key > files in place with their normal names. It's reassuring to know that > what the "rules" are. My usual approach is to have Puppet manage > everything to assert my will, but I've always worried that approach > could bite me when working with a user-friendly tool like engine-setup > so I tend to leave well enough alone on my Engine where I can. >> >>> 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. > > You've made an excellent point here that moVirt could do this, but maybe > shouldn't. I'd be happy to write up an RFE, but now am hesitant on > further reflection. I suppose it depends on why the API exposes the CA > (and presumably other) certificate details already. If it gets used > primarily by oVirt itself, e.g., compute hosts wanting to obtain these, > this isn't needed (apparently) and probably would have little to gain > for improved support of a custom web CA. On the other hand, if this API > is for all that and general consumption regardless of the need, then > this does seem like an opportunity for improvement. > > In the end I didn't have much luck getting my web cert and CA certs over > to moVirt via http as I kept getting a Android error parsing the > certificate. I then opted to use my much neglected Google Drive to > import it from a "file" instead and that went smooth as butter, even > prompting me for a Issuer cert where I gave it my intermediate CA and > when beautifully prompted again, my root CA.
Well, at least that :-)) > I already had the > intermediate and root CA certs imported into Android, but it looks like > moVirt ignores those as a general trust source. I'd say this might be a useful RFE to open on movirt, whatever its specific behavior currently is. It should be easy to make it trust the machine's trust store, perhaps by default. Thanks for the reply and the report! Best regards, > > >> >>> 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/ >>>>> >>>> >> >> > > -- > 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/4GGQEWWUNHHT4UPDWB27FZIKV727N7LX/ -- 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/MNX4NYJPQSUKO37B3OXQHQJLJI7B4DJY/
