Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1684070

Summary: Document perl-IO-Socket-SSL does not default to certificates in a working directory
Product: Red Hat Enterprise Linux 8 Reporter: Ondrej Moriš <omoris>
Component: doc-Release_Notes-8-en-USAssignee: Lucie Vařáková <lmanasko>
Status: CLOSED CURRENTRELEASE QA Contact: RHEL DPM <rhel-docs>
Severity: medium Docs Contact: Lenka Špačková <lkuprova>
Priority: medium    
Version: 8.0CC: ppisar, rhel-docs
Target Milestone: rcKeywords: Documentation
Target Release: 8.1   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-22 13:41:32 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 Ondrej Moriš 2019-02-28 11:02:10 UTC
Description of problem:

While testing basis SSL connection I noticed that there are the following two issues:

1) When a server uses a CA certificate which is not in a system-wide CA certificate store and that CA certificate is stored in ./certs/my-ca.pem, IO::Socket::SSL should use it instead missing certificate in system-wide store. But it does not work:

# openssl s_server -key localhost/key.pem -cert localhost/cert.pem -CAfile /tmp/tmp.tDhnxGMnsH/ca/cert.pem -www -accept 443 &>server.log &

# cp /tmp/tmp.tDhnxGMnsH/ca/cert.pem ./certs/my-ca.pem' (Expected 0, got 0)

# perl -MIO::Socket::SSL -e 'IO::Socket::SSL->new(PeerAddr=>q{localhost:443}, SSL_verify_mode=>SSL_VERIFY_PEER) or die qq{error $!, $SSL_ERROR}'

error , SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at -e line 1.

# cat server.log
140315817707328:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:ssl/record/rec_layer_s3.c:1528:SSL alert number 48

This is a regression when compared to RHEL-7.

2) When a server uses a CA certificate which is in a system-wide CA certificate store and SSL_ca_file=>undef argument is given to IO::Socket::SSL->new() then connection should fail. But it does not work:

# openssl s_server -key localhost/key.pem -cert localhost/cert.pem -CAfile ca/cert.pem -www -accept 443 &>server.log &

# cp ca/cert.pem /etc/pki/ca-trust/source/anchors/cacert.crt'

# update-ca-trust

# perl -MIO::Socket::SSL -e 'IO::Socket::SSL->new(PeerAddr=>q{localhost:443}, SSL_verify_mode=>SSL_VERIFY_PEER, SSL_ca_file=>undef) or die qq{error $!, $SSL_ERROR}'

# echo $?
0

This seems not to be working in RHEL-7 as well.

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

perl-IO-Socket-SSL-2.060-2.el8

How reproducible:

100%

Steps to Reproduce:

Generate CA and server certificate-key pairs and see above.

Actual results:

1) Connection does not work.
2) Connection works.

Expected results:

1) Connection should work.
2) Connection should not work.

Additional info:

N/A

Comment 1 Petr Pisar 2019-02-28 11:48:27 UTC
> 1) When a server uses a CA certificate which is not in a system-wide CA certificate
> store and that CA certificate is stored in ./certs/my-ca.pem, IO::Socket::SSL should
> use it instead missing certificate in system-wide store.

This feature was removed by upstream in IO-Socket-SSL-1.968. An excerpt from
/usr/share/doc/perl-IO-Socket-SSL/Changes:

1.968 2014/03/13
- BEHAVIOR CHANGE: removed implicit defaults of certs/server-{cert,key}.pem
  for SSL_{cert,key}_file and ca/,certs/my-ca.pem for SSL_ca_file.
  These defaults were depreceated since 1.951 (2013/7/3).

This is not a bug. I will ask highlighting this change in RHEL 8 Release Notes.

> 2) When a server uses a CA certificate which is in a system-wide CA certificate store
> and SSL_ca_file=>undef argument is given to IO::Socket::SSL->new() then connection
> should fail. But it does not work:
[...]
> # perl -MIO::Socket::SSL -e 'IO::Socket::SSL->new(PeerAddr=>q{localhost:443}, SSL_verify_mode=>SSL_VERIFY_PEER, SSL_ca_file=>undef) or die qq{error $!, $SSL_ERROR}'

Documentation reads:

  [...] If neither SSL_ca, nor SSL_ca_file or
  SSL_ca_path are set it will use "default_ca()" to determine the
  user-set or system defaults. If you really don't want to set a CA
  set SSL_ca_file or SSL_ca_path to "\undef" or SSL_ca to an empty
  list. (unfortunately '' is used by some modules using
  IO::Socket::SSL when CA is not explicitly given).

You are setting SSL_ca_file to undef, while documentation requires \undef (a reference to undef).

Observe this difference:

$ perl -MIO::Socket::SSL -e 'IO::Socket::SSL->new(PeerAddr=>q{www.google.com:443}, SSL_verify_mode=>SSL_VERIFY_PEER, SSL_ca_file=>undef) or die qq{error $!, $SSL_ERROR}'

$ perl -MIO::Socket::SSL -e 'IO::Socket::SSL->new(PeerAddr=>q{www.google.com:443}, SSL_verify_mode=>SSL_VERIFY_PEER, SSL_ca_file=>\undef) or die qq{error $!, $SSL_ERROR}'
error , SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at -e line 1.

I conclude this works as documented.

Comment 2 Petr Pisar 2019-02-28 12:09:42 UTC
(In reply to Petr Pisar from comment #1)
> > 1) When a server uses a CA certificate which is not in a system-wide CA certificate
> > store and that CA certificate is stored in ./certs/my-ca.pem, IO::Socket::SSL should
> > use it instead missing certificate in system-wide store.
> 
> This feature was removed by upstream in IO-Socket-SSL-1.968. An excerpt from
> /usr/share/doc/perl-IO-Socket-SSL/Changes:
> 
> 1.968 2014/03/13
> - BEHAVIOR CHANGE: removed implicit defaults of certs/server-{cert,key}.pem
>   for SSL_{cert,key}_file and ca/,certs/my-ca.pem for SSL_ca_file.
>   These defaults were depreceated since 1.951 (2013/7/3).
> 
> This is not a bug. I will ask highlighting this change in RHEL 8 Release
> Notes.

Please add a following paragraph to the Release Notes document (either to 4. New features, 4.7. Web servers, databases, dynamic languages, Notable changes in Perl section or to a new subsection in 8. Removed functionality, 8.2. Other removed functionality section):

IO::Socket::SSL Perl module used to load a certificate authority certificate from ./certs/my-ca.pem file or ./ca directory, server private key from ./certs/server-key.pem file, server certificate from ./certs/server-cert.pem file, client private key from ./certs/client-key.pem file, and client certificate from ./certs/client-cert.pem file. This does not happen anymore. Users are advised to specify the paths to the files explicitly.

Comment 3 Ondrej Moriš 2019-03-04 10:45:39 UTC
(In reply to Petr Pisar from comment #1)
> > 1) When a server uses a CA certificate which is not in a system-wide CA certificate
> > store and that CA certificate is stored in ./certs/my-ca.pem, IO::Socket::SSL should
> > use it instead missing certificate in system-wide store.
> 
> This feature was removed by upstream in IO-Socket-SSL-1.968. An excerpt from
> /usr/share/doc/perl-IO-Socket-SSL/Changes:
> 
> 1.968 2014/03/13
> - BEHAVIOR CHANGE: removed implicit defaults of certs/server-{cert,key}.pem
>   for SSL_{cert,key}_file and ca/,certs/my-ca.pem for SSL_ca_file.
>   These defaults were depreceated since 1.951 (2013/7/3).
> 
> This is not a bug. I will ask highlighting this change in RHEL 8 Release
> Notes.
> 
> > 2) When a server uses a CA certificate which is in a system-wide CA certificate store
> > and SSL_ca_file=>undef argument is given to IO::Socket::SSL->new() then connection
> > should fail. But it does not work:
> [...]
> > # perl -MIO::Socket::SSL -e 'IO::Socket::SSL->new(PeerAddr=>q{localhost:443}, SSL_verify_mode=>SSL_VERIFY_PEER, SSL_ca_file=>undef) or die qq{error $!, $SSL_ERROR}'
> 
> Documentation reads:
> 
>   [...] If neither SSL_ca, nor SSL_ca_file or
>   SSL_ca_path are set it will use "default_ca()" to determine the
>   user-set or system defaults. If you really don't want to set a CA
>   set SSL_ca_file or SSL_ca_path to "\undef" or SSL_ca to an empty
>   list. (unfortunately '' is used by some modules using
>   IO::Socket::SSL when CA is not explicitly given).
> 
> You are setting SSL_ca_file to undef, while documentation requires \undef (a
> reference to undef).
> 
> Observe this difference:
> 
> $ perl -MIO::Socket::SSL -e
> 'IO::Socket::SSL->new(PeerAddr=>q{www.google.com:443},
> SSL_verify_mode=>SSL_VERIFY_PEER, SSL_ca_file=>undef) or die qq{error $!,
> $SSL_ERROR}'
> 
> $ perl -MIO::Socket::SSL -e
> 'IO::Socket::SSL->new(PeerAddr=>q{www.google.com:443},
> SSL_verify_mode=>SSL_VERIFY_PEER, SSL_ca_file=>\undef) or die qq{error $!,
> $SSL_ERROR}'
> error , SSL connect attempt failed error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify failed at -e line
> 1.
> 
> I conclude this works as documented.

Petr, thank you very much for clarification, I will update our tests.