Bug 1146710 - [RFE] engine tools should use apache-ca.pem certificate for ssl and not ca.pem
Summary: [RFE] engine tools should use apache-ca.pem certificate for ssl and not ca.pem
Keywords:
Status: CLOSED DUPLICATE of bug 1445245
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: 3.5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Rob Young
QA Contact:
URL:
Whiteboard:
Depends On: 1321381 1326386
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-25 20:23 UTC by Marina Kalinin
Modified: 2019-10-10 09:25 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-12 11:30:57 UTC
oVirt Team: Integration
Target Upstream Version:
sherold: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1146712 medium CLOSED Section: "Replacing the RHEVM SSL Certificate" (D1) should be updated and moved to Tech Guide 2020-10-14 00:28:05 UTC

Internal Links: 1146712

Description Marina Kalinin 2014-09-25 20:23:05 UTC
Description of problem:
engine tools should use apache certificate and not ca.pem.
- engine-log-collector
- engine-iso-uploader
- engine-image-uploader

All those tools by default are using ca.pem.
Instead, they should use apache-ca.pem certificate.

Why does it matter?
When customer is replacing our apache certificates with customer third party ssl certs, following the procedure in the Admin Guide [1].

Another option, is update documentation [1], to update configuration files of those tools as well, as stated in our kcs solutions [2].


[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.4/html-single/Administration_Guide/index.html#Replacing_the_SSL_certificate_used_by_Red_Hat_Enterprise_Virtualization_Manager_to_identify_itself_to_users_connecting_over_https
[2]
https://access.redhat.com/solutions/458713
https://access.redhat.com/solutions/972573
https://access.redhat.com/solutions/1200943

Comment 1 Alon Bar-Lev 2014-09-25 20:28:51 UTC
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.

Comment 2 Alon Bar-Lev 2014-09-25 20:29:50 UTC
also add restapi/cli.

Comment 3 Sandro Bonazzola 2014-09-26 05:17:35 UTC
(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

Comment 4 Sandro Bonazzola 2014-09-26 05:29:01 UTC
(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 .

Comment 5 Alon Bar-Lev 2014-09-26 06:35:30 UTC
(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

Comment 6 Sandro Bonazzola 2014-09-26 07:04:04 UTC
(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?

Comment 7 Alon Bar-Lev 2014-09-26 07:12:18 UTC
(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?

Comment 8 Sandro Bonazzola 2014-09-26 07:17:19 UTC
(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?

Comment 9 Alon Bar-Lev 2014-09-26 07:21:44 UTC
(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

Comment 10 Sandro Bonazzola 2014-09-26 07:25:24 UTC
Ok, it amke sense.

Comment 11 Marina Kalinin 2014-10-01 00:29:49 UTC
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?

Comment 12 Alon Bar-Lev 2014-10-01 05:56:35 UTC
(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.

Comment 13 Marina Kalinin 2014-10-07 20:04:01 UTC
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?

Comment 14 Alon Bar-Lev 2014-10-07 20:13:17 UTC
/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.

Comment 15 Marina Kalinin 2014-10-07 20:43:25 UTC
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!

Comment 25 Paul Armstrong 2016-04-05 21:01:28 UTC
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

Comment 28 Marina Kalinin 2016-04-26 21:00:02 UTC
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.

Comment 29 Marina Kalinin 2016-04-26 21:13:50 UTC
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

Comment 30 Simone Tiraboschi 2016-05-02 08:52:39 UTC
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.

Comment 31 Marina Kalinin 2016-06-17 21:18:49 UTC
I think we simply need a tool that will replace the apache cert with the input third party cert and will handle all this.

Comment 32 Yaniv Kaul 2017-06-07 21:53:08 UTC
(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?

Comment 33 Sandro Bonazzola 2017-06-14 14:01:21 UTC
(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.

Comment 34 Yaniv Lavi 2018-06-12 11:30:57 UTC
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.

Comment 35 Yedidyah Bar David 2018-06-13 05:57:54 UTC
logcollector's default was changed in bug 1445245. The uploaders are deprecated IIUC.

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

Comment 36 Franta Kust 2019-05-16 13:05:52 UTC
BZ<2>Jira Resync


Note You need to log in before you can comment on or make changes to this bug.