Bug 1402787 - Should default SSL_ca_file to global store
Summary: Should default SSL_ca_file to global store
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-IO-Socket-SSL
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-12-08 10:57 UTC by Brian J. Murrell
Modified: 2017-01-26 15:54 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1402588
Last Closed: 2017-01-26 15:54:53 UTC
Type: Bug

Attachments (Terms of Use)

Description Brian J. Murrell 2016-12-08 10:57:40 UTC
I suspect this issue applies to Fedora also.

+++ This bug was initially created as a clone of Bug #1402588 +++

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.

--- Additional comment from Petr Pisar on 2016-12-08 02:45:19 EST ---

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.

--- Additional comment from Brian J. Murrell on 2016-12-08 05:55:52 EST ---

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 1 Petr Pisar 2016-12-08 12:42:22 UTC
Brian, Fedora's perl-IO-Socket-SSL-2.039-1.fc26.noarch does verify by default and it does use distribution-wide certificate store by default. Or do you have different experience?

Comment 2 Paul Howarth 2016-12-09 11:31:01 UTC
Upstream added default_ca in version 1.968, warned on verification failures from version 1.967 and required use of verify_none to disable verification checks from 2.018.

All current Fedora releases have at least version 2.023.

Comment 3 Paul Howarth 2017-01-26 15:54:53 UTC
I don't think this affects Fedora, hence closing.

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