Bug 736120 - uw-imap-2007e-14.el6.i686 + libc-client-2007e-11.el6.i686 can't establish encrypted connections
uw-imap-2007e-14.el6.i686 + libc-client-2007e-11.el6.i686 can't establish enc...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libc-client (Show other bugs)
6.2
i686 Linux
unspecified Severity high
: rc
: ---
Assigned To: Joe Orton
qe-baseos-daemons
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-06 14:32 EDT by Petko Alov
Modified: 2014-10-30 19:05 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-30 19:05:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
.spec patch to define ssldir macro (994 bytes, patch)
2012-03-30 14:32 EDT, Rex Dieter
no flags Details | Diff
Fix for spec patch (643 bytes, patch)
2012-07-31 14:12 EDT, Michael Diamond
no flags Details | Diff

  None (edit)
Description Petko Alov 2011-09-06 14:32:18 EDT
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 15:29:27 EDT
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 13:37:26 EDT
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 13:45:23 EDT
Thanks, I think those log errors gives me a hint for what to look for.
Comment 4 Rex Dieter 2012-03-30 13:52:30 EDT
Doh, that's part of libc-client api!   Re-assigning.
Comment 5 Rex Dieter 2012-03-30 13:53:40 EDT
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 14:32:07 EDT
Created attachment 574065 [details]
.spec patch to define ssldir macro
Comment 8 Joe Orton 2012-03-30 14:35:29 EDT
Thanks for the patch, Rex.
Comment 9 bkamen 2012-07-14 15:02:46 EDT
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 15:03:48 EDT
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 14:12:46 EDT
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 10:27:39 EDT
fyi, the bug is in the rhel libc-client pkg, not epel's uw-imap
Comment 13 RHEL Product and Program Management 2012-09-07 01:11:53 EDT
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 Product and Program Management 2014-10-30 19:05:46 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

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