Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1123509

Summary:	Deprecate the [server] ssl_ca_certificate setting, replacing with a new CA path setting
Product:	[Retired] Pulp	Reporter:	Randy Barlow <rbarlow>
Component:	z_other	Assignee:	pulp-bugs
Status:	CLOSED UPSTREAM	QA Contact:	pulp-qe-list
Severity:	medium	Docs Contact:
Priority:	medium
Version:	Master	CC:	jortel, skarmark
Target Milestone:	---	Keywords:	Triaged
Target Release:	3.0.0
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-28 22:13:39 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Randy Barlow 2014-07-25 21:29:02 UTC

We currently have a setting in the [server] section of server.conf called ssl_ca_certificate. It must be a path to a specific CA certificate that is used for consumer yum repo files to validate that the Yum repository's SSL certificate is trusted.

Unfortunately there is also a setting called ca_cert, which is the certificate that Pulp uses to sign client certificates for authentication. These settings have little to do with one another yet have a meaning conflict in their names.

This should be removed. Instead we should have a consumer bool setting (i.e., not in server.conf) that allows the user to specify whether Yum should validate the server's signature with an authority pack. Additionally, a setting for a path to a directory containing certificates should be created so the user can provide their own certificate packs if they wish.

Comment 1 Randy Barlow 2014-11-18 20:55:56 UTC

I think this might be important to do with 3.0. This setting cannot be used in a safe way, because it requires the consumer machine to have already registered and to have bound a repo before it can take any effect. This means that the consumer machines must already have trust on Pulp's CA certificate since they cannot safely use pulp-consumer without it. If the consumer machines already have trust on Pulp's CA, this setting isn't useful.

This setting also has a lot of potential for confusion, since it has such a general name and since its name is extremely similar to the cacert setting.

I'll untriage it so its priority and target release can be reconsidered. I've also removed the FutureFeature and RFE tags since this isn't really a feature but is truly a defect.

Comment 2 Randy Barlow 2014-11-18 21:01:29 UTC

Maybe we can go ahead and deprecate this setting now, but remove it in 3.0. Should we have two bugs for this? One for derecation (this one), and another for removal?

Comment 3 Jeff Ortel 2014-11-24 16:54:32 UTC

2.6 just deprecates the setting.  On completion, re-assign to 3.0.

Comment 4 Sayli Karmarkar 2015-01-07 08:52:59 UTC

https://github.com/pulp/pulp/pull/1491. Not moving to POST. Once the PR is approved and merged, this bug will be moved to 3.0 target release for actually removing the settings.

Comment 5 Sayli Karmarkar 2015-01-12 18:25:40 UTC

Merged https://github.com/pulp/pulp/pull/1491. Moving to 3.0 target relase.

Comment 6 Brian Bouterse 2015-02-28 22:13:39 UTC

Moved to https://pulp.plan.io/issues/475