Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1210878 - [RFE] Allow user to disable SSL verification for custom repositories hosted via SSL
[RFE] Allow user to disable SSL verification for custom repositories hosted v...
Status: CLOSED ERRATA
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Repositories (Show other bugs)
6.0.8
Unspecified Unspecified
unspecified Severity medium (vote)
: Beta
: Unused
Assigned To: satellite6-bugs
Peter Ondrejka
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-04-10 15:01 EDT by Rich Jerrido
Modified: 2018-02-21 07:29 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-02-21 07:29:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 15802 None None None 2017-10-12 09:36 EDT
Red Hat Product Errata RHSA-2018:0336 normal SHIPPED_LIVE Important: Satellite 6.3 security, bug fix, and enhancement update 2018-02-21 17:43:42 EST

  None (edit)
Description Rich Jerrido 2015-04-10 15:01:08 EDT
Description of problem:
As a user, I have multiple yum repositories that I wish to use with Satellite 6. These repositories are internal to my organization, and are hosted via SSL via self-signed certificates. 

When synchronizing these repositories in Satellite 6, synchronization fails with

"[Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"

Version-Release number of selected component (if applicable):
foreman-1.6.0.53-1.el6sat.noarch
foreman-compute-1.6.0.53-1.el6sat.noarch
foreman-discovery-image-6.5-20140620.2.el6sat.noarch
foreman-gce-1.6.0.53-1.el6sat.noarch
foreman-libvirt-1.6.0.53-1.el6sat.noarch
foreman-ovirt-1.6.0.53-1.el6sat.noarch
foreman-postgresql-1.6.0.53-1.el6sat.noarch
foreman-proxy-1.6.0.33-1.el6sat.noarch
foreman-selinux-1.6.0.14-1.el6sat.noarch
foreman-vmware-1.6.0.53-1.el6sat.noarch
katello-1.5.0-30.el6sat.noarch
katello-certs-tools-1.5.6-1.el6sat.noarch
katello-default-ca-1.0-1.noarch
katello-installer-0.0.67-1.el6sat.noarch
katello-server-ca-1.0-1.noarch
pulp-katello-0.3-4.el6sat.noarch
pulp-nodes-common-2.4.4-1.el6sat.noarch
pulp-nodes-parent-2.4.4-1.el6sat.noarch
pulp-puppet-plugins-2.4.4-1.el6sat.noarch
pulp-puppet-tools-2.4.4-1.el6sat.noarch
pulp-rpm-plugins-2.4.4-1.1.el6sat.noarch
pulp-selinux-2.4.4-1.el6sat.noarch
pulp-server-2.4.4-1.el6sat.noarch


How reproducible:
100%

Steps to Reproduce:
1. Create a custom product
2. Create a repository of type 'yum' associated with the custom product
3. Set the URL to https://foo.bar.com where https://foo.bar.com has a self-signed cert. 
4. Attempt to sync the repository. 

Actual results:

"[Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"

Expected results:

The repository should be synchronized. 

Additional info:

This RFE requests the ability to disable SSL verification on a per-repository basis, with the appropriate options in hammer-cli and the API to do the same.
Comment 1 RHEL Product and Program Management 2015-04-10 15:13:31 EDT
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
Comment 3 Bryan Kearney 2015-10-01 10:55:59 EDT
If I can find a way to put a self signed CA in the chain of trust, is that sufficient?
Comment 4 Bryan Kearney 2015-10-01 11:55:08 EDT
Note, you can add the self signed CA to the OS CA store using update-ca-trust. This can be done w/o a pulp restart. Or you can use

http://pulp.readthedocs.org/en/latest/user-guide/installation.html?highlight=ca_path#signed-certificates

and restart pulp
Comment 5 Rich Jerrido 2015-10-02 07:38:41 EDT
(In reply to Bryan Kearney from comment #3)
> If I can find a way to put a self signed CA in the chain of trust, is that
> sufficient?

In a strict sense, yes. However, I am not a fan of updating the operating systems CA store because:

* It assumes the user of Satellite is the 'root' user on the system running Satellite. (Many Satellites will be deployed in a multi-org configuration where this is not the case)

* It allows any other applications which use the OS' CA store to connect to any other website/service which is signed via the same CA (which may or may not be desirable)

* It is a workflow that I cannot drive via Satellite's UI (and the API & CLI). 

For these reasons I still favor having 'perform SSL Verification' as a property of the repository itself, allowing the user to toggle it on/off as per their needs.
Comment 7 Bryan Kearney 2016-01-15 08:06:04 EST
Michael: Should I add a version of this to an upstream pulp bug? Seems like I need it in pulp first, then katello to expose it.
Comment 8 Michael Hrivnak 2016-01-15 15:54:37 EST
Pulp already has both options. Per-repo, or even per-sync if you like, you can provide a CA cert to use for verification, or turn off SSL verification.

See the settings "ssl_ca_cert" and "ssl_verification"

http://pulp-rpm.readthedocs.org/en/2.6-release/tech-reference/yum-plugins.html#configuration-parameters

+1 to all of Rich's comments in #5.

I think this is ready for katello to expose in the UI.
Comment 9 Bryan Kearney 2016-08-04 16:11:15 EDT
Moving 6.2 bugs out to sat-backlog.
Comment 11 Justin Sherrill 2017-10-12 09:38:14 EDT
This is resolved upstream and will appear in satellite 6.3.0, re-aligning.  Feel free to correct any knob i pulled incorrectly :)
Comment 12 Peter Ondrejka 2017-12-06 10:21:02 EST
Verified in Sat 6.3 snap 27, verify ssl option has been added to repository options.
Comment 15 errata-xmlrpc 2018-02-21 07:29:34 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336

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