Bug 736120

Summary: uw-imap-2007e-14.el6.i686 + libc-client-2007e-11.el6.i686 can't establish encrypted connections
Product: Red Hat Enterprise Linux 6 Reporter: Petko Alov <petko>
Component: libc-clientAssignee: Joe Orton <jorton>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.2CC: bkamen, knox, rdieter
Target Milestone: rcKeywords: Patch, Reopened
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-10-17 07:31:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
.spec patch to define ssldir macro
none
Fix for spec patch none

Description Petko Alov 2011-09-06 18:32:18 UTC
Description of problem:

imapd and ipop3d (from uw-imap-2007e-14.el6.i686 from EPEL with installed for dependency libc-client-2007e-11.el6.i686 from base) can establish unencrypted but not encrypted connections with any mail-client

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

Centos 6.0 i386
uw-imap-2007e-14.el6.i686
libc-client-2007e-11.el6.i686

How reproducible:

invariably

Steps to Reproduce:
1. Install uw-imap and dependencies
2. Create imapd.pem and ipop3d.pem in /etc/pki/tls/certs/
3. Connect to imaps/pop3s with SSL/TLS or imap/pop3 with STARTTLS
  
Actual results:

No encrypted connection could be established

Expected results:

Establishing of encrypted connection

Additional info:

Problem seems related to libc-client-2007e-11.el6.i686 from base repository - replacing uw-imap-2007e-14.el6.i686 with uw-imap-2007e-14.el5.i386 exhibits the same problem, while replacing also libc-client-2007e-11.el6.i686 with libc-client2007-2007e-14.el5.i386 from EPEL solves the problem

Comment 1 Charles Knox 2012-03-28 19:29:27 UTC
The errors in the maillog from a system with this problem are of the form:

Mar 28 14:36:42 myimaphost imapd[4975]: imaps SSL service init from xx.xx.xx.xx
Mar 28 14:36:42 myimaphost imapd[4975]: Unable to load certificate from %{ssldir}/certs/imapd.pem, host=somehost.somedomain.sometld [xx.xx.xx.xx]
Mar 28 14:36:42 myimaphost imapd[4975]: SSL error status: error:02001002:system library:fopen:No such file or directory
Mar 28 14:36:42 myimaphost imapd[4975]: SSL error status: error:20074002:BIO routines:FILE_CTRL:system lib
Mar 28 14:36:42 myimaphost imapd[4975]: SSL error status: error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib

This is on a RHEL6 i386 workstation installation which is acting as the imap host.  The system is patched to current as of 28 March 2012.  

I have done a compile from source of the current UWashington source file from 

ftp://ftp.cac.washington.edu/imap/imap-2007f.tar.gz

using the command 

make lr5

as suggested in the UW README file.  The code compiles with some warnings of incompatible pointer types, and that the use of "tmpnam" and "gets" are dangereous.  As I only use the imaps functionality I copied the compiled executable to /usr/sbin to replace the RPM's executable and things now work.

If I tried to use make lrh I got the following warning:
[root@myimaphost imap-2007f]# make lrh
make[1]: Entering directory `/root/system/UW-IMAP/imap-2007f'
You are building for OLD versions of RedHat Linux. This build
is NOT suitable for RedHat Enterprise 5, which stores SSL/TLS
certificates and keys in /etc/pki/tls rather than /usr/share/ssl.
If you want to build for modern RedHat Linux, you should use
make lr5 instead.
Do you want to continue this build? Type y or n please:


It seems that the issue is with the definition of the SSL certs directory.

Comment 2 Charles Knox 2012-03-30 17:37:26 UTC
The errors in the maillog from a system with this problem are of the form:

Mar 28 14:36:42 myimaphost imapd[4975]: imaps SSL service init from xx.xx.xx.xx
Mar 28 14:36:42 myimaphost imapd[4975]: Unable to load certificate from %{ssldir}/certs/imapd.pem, host=somehost.somedomain.sometld [xx.xx.xx.xx]
Mar 28 14:36:42 myimaphost imapd[4975]: SSL error status: error:02001002:system library:fopen:No such file or directory
Mar 28 14:36:42 myimaphost imapd[4975]: SSL error status: error:20074002:BIO routines:FILE_CTRL:system lib
Mar 28 14:36:42 myimaphost imapd[4975]: SSL error status: error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib

This is on a RHEL6 i386 workstation installation which is acting as the imap host.  The system is patched to current as of 28 March 2012.  

I have done a compile from source of the current UWashington source file from 

ftp://ftp.cac.washington.edu/imap/imap-2007f.tar.gz

using the command 

make lr5

as suggested in the UW README file.  The code compiles with some warnings of incompatible pointer types, and that the use of "tmpnam" and "gets" are dangereous.  As I only use the imaps functionality I copied the compiled executable to /usr/sbin to replace the RPM's executable and things now work.

If I tried to use make lrh I got the following warning:
[root@myimaphost imap-2007f]# make lrh
make[1]: Entering directory `/root/system/UW-IMAP/imap-2007f'
You are building for OLD versions of RedHat Linux. This build
is NOT suitable for RedHat Enterprise 5, which stores SSL/TLS
certificates and keys in /etc/pki/tls rather than /usr/share/ssl.
If you want to build for modern RedHat Linux, you should use
make lr5 instead.
Do you want to continue this build? Type y or n please:


It seems that the issue is with the definition of the SSL certs directory.

Comment 3 Rex Dieter 2012-03-30 17:45:23 UTC
Thanks, I think those log errors gives me a hint for what to look for.

Comment 4 Rex Dieter 2012-03-30 17:52:30 UTC
Doh, that's part of libc-client api!   Re-assigning.

Comment 5 Rex Dieter 2012-03-30 17:53:40 UTC
Joe, check to make sure %{ssldir} is getting defined right in libc-client packaging.  I use this snippet:

# FC4+ uses %%_sysconfdir/pki/tls, previous releases used %%_datadir/ssl
%global ssldir  %(if [ -d %{_sysconfdir}/pki/tls ]; then echo "%{_sysconfdir}/pki/tls"; else echo "%{_datadir}/ssl"; fi)

or you could just hard-code to the known-right place.  As-is, it seems the %{ssldir} macro is undefined

Comment 7 Rex Dieter 2012-03-30 18:32:07 UTC
Created attachment 574065 [details]
.spec patch to define ssldir macro

Comment 8 Joe Orton 2012-03-30 18:35:29 UTC
Thanks for the patch, Rex.

Comment 9 bkamen 2012-07-14 19:02:46 UTC
Hi All,

If I may note: this same problem occurs in the x86_64 version as well.

For me, I installed uw-imap-2007e-14.el6.x86_64I on Apr 29.

I'm guessing this update has not made it to the EPEL packages repository? 

Just wondering,

 Thanks!

 -Ben

Comment 10 bkamen 2012-07-14 19:03:48 UTC
Erp, that's uw-imap-2007e-14.el6.x86_64 withOUT the I on the end. Typo. Sorry.

Comment 11 Michael Diamond 2012-07-31 18:12:46 UTC
Created attachment 601556 [details]
Fix for spec patch

I recently upgraded to CentOS 6.3 (Final) and discovered that secure imap connections are broken in the current release. A Google search got me here and I applied the patch (with minor fix, see attached). Thank you.

Apparently this has been broken for almost a year and the fix has been available for four months and yet it still hasn't been pushed to EPEL!

IMAPS is a pretty important service. This is a high severity bug and this may bite a lot of people. What's the delay in pushing the fix out?

Comment 12 Rex Dieter 2012-08-03 14:27:39 UTC
fyi, the bug is in the rhel libc-client pkg, not epel's uw-imap

Comment 13 RHEL Program Management 2012-09-07 05:11:53 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 15 RHEL Program Management 2014-10-30 23:05:46 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 16 Rex Dieter 2017-07-11 04:58:46 UTC
Wow, sad rhel chooses to continue to ship a broken package, I guess I'll have to work around it in epel by (essentially) using a fixed bundled copy instead

Comment 17 Fedora Update System 2017-07-11 16:03:41 UTC
uw-imap-2007f-14.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-03a17c3c29

Comment 18 Fedora Update System 2017-07-12 03:46:34 UTC
uw-imap-2007f-14.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-03a17c3c29