RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1402588 - Should default SSL_ca_file to global store
Summary: Should default SSL_ca_file to global store
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: perl-IO-Socket-SSL
Version: 7.2
Hardware: x86_64
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Petr Pisar
QA Contact: Eva Mrakova
Lenka Špačková
Depends On:
Blocks: 1420851 1465904 1466370
TreeView+ depends on / blocked
Reported: 2016-12-07 22:02 UTC by Brian J. Murrell
Modified: 2020-08-13 08:45 UTC (History)
8 users (show)

Fixed In Version: perl-IO-Socket-SSL-1.94-7.el7
Doc Type: Release Note
Doc Text:
The *IO::Socket::SSL* Perl module now uses the system-wide CA certificate store by default Previously, if a TLS application based on the *IO::Socket::SSL* Perl module did not provide an explicit path to a certificate authority (CA) certificate, no authority was known, and the peer's identity could not be verified. With this update, the module uses the system-wide CA certificate store by default. However, it is possible to disable any certificate store by passing the `undef` value to the `SSL_ca_file` option of the `IO::Socket::SSL->new()` constructor.
Clone Of:
: 1402787 1835755 (view as bug list)
Last Closed: 2018-04-10 10:02:54 UTC
Target Upstream Version:

Attachments (Terms of Use)
Support for defaulting to system-wide CA store (5.77 KB, patch)
2016-12-08 15:20 UTC, Petr Pisar
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0688 0 None None None 2018-04-10 10:03:06 UTC

Description Brian J. Murrell 2016-12-07 22:02:32 UTC
Description of problem:
When writing/using a perl script that wants to use SSL via perl-IO-Socket-SSL I am required to point the library at the default global certificate store.  I shouldn't have to do that as a default behavioura.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Write a perl script to make an SSL connection but don't set SSL parameters

Actual results:
connect failed: Unable to start TLS: SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Expected results:
Should get a successful connection

Additional info:
In my script, where I am using perl-Mail-IMAPClient as a consumer of perl-IO-Socket-SSL in order to avoid the nasty error above I have to include

SL_ca_file => '/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem'

Given that that is just pointing at the existing global default certificate store, I really ought not need to do this.

While I am at it, I would also argue that SSL_verify_mode => SSL_VERIFY_PEER be default forcing one to set it otherwise if one wants to ignore certificate verification such as one has to do with other tools like curl's -k argument, etc.

Comment 1 Petr Pisar 2016-12-08 07:45:19 UTC
You complain about this warning you get if you do not set the values explicitly:

 Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
 is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
 together with SSL_ca_file|SSL_ca_path for verification.
 If you really don't want to verify the certificate and keep the
 connection open to Man-In-The-Middle attacks please set
 SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.

This is a documented feature of IO-Socket-SSL-1.94 that was the latest current when Red Hat Enterprise Linux version 7 was created.

If you request changing the default behavior, please contact Red Hat support to help you with evaluating and escalating your issue properly.

Comment 2 Brian J. Murrell 2016-12-08 10:55:52 UTC
I'm not saying that it's not the default behaviour upstream.  What I am saying is that Red Hat's engineering and market focus means that it can do better than what is upstream.

Upstream have no idea where the certificate store is for a given installation or who their users are.

Red Hat does, on both counts.  Red Hat's engineering provide systems with a central/global certificate store and Red Hat knows it has enterprise users who are interested in security.  Both of those, IMHO, mean that Red Hat can adjust this default behaviour to provide an overall better integrated experience.

Comment 3 Petr Pisar 2016-12-08 11:17:18 UTC
Default CA path is not the issue (you can use Mozilla::CA::SSL_ca_file from perl-Mozilla-CA that knows the correct location). The issue is enabling verification by default. This could break working systems of those who did not import CA certificate into their system.

If you wish this change to be implemented please contact Red Hat support.

Comment 5 Petr Pisar 2016-12-08 15:20:49 UTC
Created attachment 1229520 [details]
Support for defaulting to system-wide CA store

This patch implements defaulting to system-wide CA store if SSL_ca_file option is not pasted with undef value.

Comment 6 Petr Pisar 2016-12-08 15:29:53 UTC
How to test:

(1) Check an IO::Socket::SSL connection uses a system-wide CA certificate store by default by executing:

$ perl -MIO::Socket::SSL -e 'IO::Socket::SSL->new(PeerHost=>q{bugzilla.redhat.com}, PeerPort=>443, SSL_verify_mode=>SSL_VERIFY_PEER) or die qq{error $!, $SSL_ERROR\n}'

Before: An error is reported like this:
error , IO::Socket::IP configuration failed SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

After: No error is reported.

(2) Check a connection to a server with uknown authority fails.

(3) You can also check that running the code from a directory that has certs/my-ca.pem file will use that file by default instead of the system-wide store.

(4) You can also check that passing SSL_ca_file=>undef arguments to the IO::Socket::SSL->new() will prevent from using the system-wide store.

Comment 7 David Steele 2017-06-19 19:52:37 UTC
I'm seeing the same issue and this patch works for me.  Any chance this will make it into an update soon?

Comment 8 Petr Pisar 2017-06-22 06:56:40 UTC
There is no chance if customer does not reach out Red Hat Support.

Comment 25 errata-xmlrpc 2018-04-10 10:02:54 UTC
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.


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