I think that tools should use their own settings and not complete with engine... but it is too late for that. using apache-ca at engine machine is good compromise, question what is to be done in remote servers.

So maybe best to have configuration of tools, or have /etc/pki/xxx/yyy which is symlink to other path... I do not like this as the tools should not require any privileged artifact to run, nor look into /etc.

also add restapi/cli.

(In reply to Marina from comment #0)
> Description of problem:
> engine tools should use apache certificate and not ca.pem.
> - engine-log-collector
> - engine-iso-uploader
> - engine-image-uploader

Keeping this bug for engine-log-collector, please clone to iso-uploader and to image-uploader

(In reply to Alon Bar-Lev from comment #1)
> I think that tools should use their own settings and not complete with
> engine... but it is too late for that. using apache-ca at engine machine is
> good compromise, question what is to be done in remote servers.

the configuration is available:
cert_file key in the config file just defaults to /etc/pki/ovirt-engine/ca.pem if not specified in command line or in config file.

> 
> So maybe best to have configuration of tools, or have /etc/pki/xxx/yyy which
> is symlink to other path... I do not like this as the tools should not
> require any privileged artifact to run, nor look into /etc.

What about defaulting to /etc/pki/ovirt-log-collector/ca.pem and having engine-setup creating the symlink to apache-ca.pem ?
If the tool is installed on a different host, user must supply /etc/pki/ovirt-log-collector/ca.pem .

(In reply to Sandro Bonazzola from comment #4)
> (In reply to Alon Bar-Lev from comment #1)
> > I think that tools should use their own settings and not complete with
> > engine... but it is too late for that. using apache-ca at engine machine is
> > good compromise, question what is to be done in remote servers.
> 
> the configuration is available:
> cert_file key in the config file just defaults to
> /etc/pki/ovirt-engine/ca.pem if not specified in command line or in config
> file.
> 

yes, I understand, but it assumes that someone has put it there... it is same as assuming apache-ca.pem...

> > 
> > So maybe best to have configuration of tools, or have /etc/pki/xxx/yyy which
> > is symlink to other path... I do not like this as the tools should not
> > require any privileged artifact to run, nor look into /etc.
> 
> What about defaulting to /etc/pki/ovirt-log-collector/ca.pem and having
> engine-setup creating the symlink to apache-ca.pem ?
> If the tool is installed on a different host, user must supply
> /etc/pki/ovirt-log-collector/ca.pem .

this is the above suggestion... not sure I like any default but /etc/ssl/certs/ca-certificates.crt

I do not remember, do these tools support conf.d at /etc/?

If so, the default can be /etc/ssl/certs/ca-certificates.crt while engine-setup can put configuration file and modify it to /etc/pki/ovirt-log-collector/ca.pem

(In reply to Alon Bar-Lev from comment #5)
> this is the above suggestion... not sure I like any default but
> /etc/ssl/certs/ca-certificates.crt
> 
> I do not remember, do these tools support conf.d at /etc/?

Yes, they support conf.d

> If so, the default can be /etc/ssl/certs/ca-certificates.crt while
> engine-setup can put configuration file and modify it to
> /etc/pki/ovirt-log-collector/ca.pem

ok, it can be done like that. setup must also create the symlink from /etc/pki/ovirt-engine/ca.pem to /etc/pki/ovirt-log-collector/ca.pem.
Correct?

(In reply to Sandro Bonazzola from comment #6)
> (In reply to Alon Bar-Lev from comment #5)
> > this is the above suggestion... not sure I like any default but
> > /etc/ssl/certs/ca-certificates.crt
> > 
> > I do not remember, do these tools support conf.d at /etc/?
> 
> Yes, they support conf.d
> 
> > If so, the default can be /etc/ssl/certs/ca-certificates.crt while
> > engine-setup can put configuration file and modify it to
> > /etc/pki/ovirt-log-collector/ca.pem
> 
> ok, it can be done like that. setup must also create the symlink from
> /etc/pki/ovirt-engine/ca.pem to /etc/pki/ovirt-log-collector/ca.pem.
> Correct?

no need... as if it is in configuration file, then default can be:

/etc/ssl/certs/ca-certificates.crt

and engine-setup can override it using:

/etc/pki/ovirt-engine/apache-ca.pem

This is how it should be... our problem... backward compatibility...  as current default is /etc/pki/ovirt-engine/ca.pem, what I suggest is when upgrading tool put this previous default in /etc/*.conf.d but have sane above default.

What do you think?

(In reply to Alon Bar-Lev from comment #7)
> This is how it should be... our problem... backward compatibility...  as
> current default is /etc/pki/ovirt-engine/ca.pem, what I suggest is when
> upgrading tool put this previous default in /etc/*.conf.d but have sane
> above default.
> 
> What do you think?

isn't /etc/pki/ovirt-engine/apache-ca.pem valid also for previous versions?
if so, using /etc/pki/ovirt-engine/apache-ca.pem or /etc/pki/ovirt-engine/ca.pem while upgrading shouldn't be an issue. Or am I missing something?

(In reply to Sandro Bonazzola from comment #8)
> (In reply to Alon Bar-Lev from comment #7)
> > This is how it should be... our problem... backward compatibility...  as
> > current default is /etc/pki/ovirt-engine/ca.pem, what I suggest is when
> > upgrading tool put this previous default in /etc/*.conf.d but have sane
> > above default.
> > 
> > What do you think?
> 
> isn't /etc/pki/ovirt-engine/apache-ca.pem valid also for previous versions?
> if so, using /etc/pki/ovirt-engine/apache-ca.pem or
> /etc/pki/ovirt-engine/ca.pem while upgrading shouldn't be an issue. Or am I
> missing something?

yes it is valid, but as you actually use ca.pem I though it is safe to use the same regardless of what in apache-ca.pem when tool is upgraded (I am not referring to engine-setup based upgrade).

in enigne-setup based you can override the tool default and the above fixup with another conf.d to refer to apache-ca.pem

Ok, it amke sense.

Let me try summarizing and see if it makes sense:
~~~
- Log collector (or any of the other tools) would have a default certificate under /etc/ssl/certs/ca-certificates.crt. 
Who will create it and when?

- "..and engine-setup can override it using:"
/etc/pki/ovirt-engine/apache-ca.pem
~~~

Does not make sense to me. Probably I am missing the point here.
Adding more certificates and to other locations would be even more confusing.


Can you please clarify the flow of events and certificates to be used?

(In reply to Marina from comment #11)
> - Log collector (or any of the other tools) would have a default certificate
> under /etc/ssl/certs/ca-certificates.crt. 
> Who will create it and when?

this is the default openssl trust, which are globally approved certificate authorities. in most cases of 3rd party certificates this will work without additional configuration. so if you set up engine with 3rd party certificate of approved authority, then install api/cli/logcollector at different machine it will work without any additional configuration.

Alon, I think there was my personal confusion between ssl and pki.
For ssl communication and the apache.ca specifically, the default linux location is /etc/ssl. While the Public Key Infrastructure defaults to /etc/pki. Makes sense now.

Next is to understand what would be the best solution for engine.
Just for the record, we didn't hear about any customer running those tool from other then rhevm machine. (not talking about api or cli separately).
So, the default ssl certificate for engine and tools would be located under /etc/ssl/certs/ca-certificates.crt. And /etc/pki/ovirt-engine/apache-ca.pem would be a symlink to the default location. Correct?
Also, I suggest to add a command line option for specifying ca-cert for the tools, in addition to the conf file.


Last: let's define to what is affected and if this bug needs to be cloned.
- RHEV-H installation, initiated from the host and uses ssl to download ssh keys.
- log-collector / iso-uploader / image-uploader
- api / cli.

Do we really need a separate bug for each or maybe we can change a title of this bug and make it more global?

/etc/pki is convention of redhat distributions of storing pki artifacts. we are talking about log-collector / iso-uploader / image-uploader / api / cli for using default python/java trust which is actually based on openssl.

opening rfe for each component should be done by pm/r&d in my opinion... you can move this bug to RFEs, so that it will be clear.

Scott,
As discussed earlier in the bug (#0, #13, #14), changing this bug to RFE.

RHEV seems to have misconception about ssl certificate to be used by its different tools. And a change is required across all those tools within the product. 

We do have workarounds for all the known issues related. That's why it is not high priority. However, this behaviour definitely should be reviewed and redone in a more convenient way. It will make the product much easier and convenient to use and to support.

Please review, triage and clone to relevant component if needed.

Thank you!

Unfortunately, I no longer has time to pursue this matter. I have to reinstall in order to prepare for a presentation to a customer. 

Please close this issue. If it arises again, I will create a new bz

Regards,

Paul

I still think it should be a bug and not RFE.
I do not think it should be closed won't fix. 
I think it should be opened and addressed the sooner the better.
If we close it now, it will continue (it probably continues) same wrong behavior in 4.0 as well.

It should be as simple as pointing all the tools to use apache-ca.pem rather then ca.pm. We don't have to go and reimplement everything as was discussed in the bug. But to make sure that all the tools that are accessing the engine through https(restAPI) should use the correct certificate, which is apache-ca.pm.

Bugs like this would just not exists then:
https://bugzilla.redhat.com/show_bug.cgi?id=1254838
And we would have less customer cases to explain them over and over again that they need to reconfigure their tools once they have third party cert installed.

As for now I've opened a documentation bug to cover this in the docs to provide an immediate resolution. However we should NOT close this bug wontfix.

https://bugzilla.redhat.com/show_bug.cgi?id=1330754

All our tools are basically based on the oVirt Python SDK.
The issue on my opinion is just that the oVirt Python SDK ignores the system wide CA chains.

As a user I'd expect that if I replace the oVirt custom cert with one commercially  signed by a trusted CA it would be automatically accepted everywhere (and revocation lists are taken in care and so on).
The same if I replace with a cert signed by my company CA and I already trusted it on my hosts.

I think we simply need a tool that will replace the apache cert with the input third party cert and will handle all this.

(In reply to Marina from comment #31)
> I think we simply need a tool that will replace the apache cert with the
> input third party cert and will handle all this.

Via Ansible?

(In reply to Yaniv Kaul from comment #32)
> (In reply to Marina from comment #31)
> > I think we simply need a tool that will replace the apache cert with the
> > input third party cert and will handle all this.
> 
> Via Ansible?

Make sense.

Closing old RFEs, please reopen if still needed.
Patches are always welcome.
We will be looking to add a RFE on a Ansible script to automate the SSL certs replacement.

logcollector's default was changed in bug 1445245. The uploaders are deprecated IIUC.

*** This bug has been marked as a duplicate of bug 1445245 ***

BZ<2>Jira Resync