Red Hat Bugzilla – Bug 736120
uw-imap-2007e-14.el6.i686 + libc-client-2007e-11.el6.i686 can't establish encrypted connections
Last modified: 2017-07-11 23:46:34 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
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.
Thanks, I think those log errors gives me a hint for what to look for.
Doh, that's part of libc-client api! Re-assigning.
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
Created attachment 574065 [details] .spec patch to define ssldir macro
Thanks for the patch, Rex.
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
Erp, that's uw-imap-2007e-14.el6.x86_64 withOUT the I on the end. Typo. Sorry.
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?
fyi, the bug is in the rhel libc-client pkg, not epel's uw-imap
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.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
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
uw-imap-2007f-14.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-03a17c3c29
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