Menu
▾
▴
[fetchmail-devel] [Bug #17073] ssl certificate verification broken in fetchmail 6.3.16
|
From: <ad...@be...> - 2010-04-12 17:10:16
|
Bug #17073, was updated on 2010-Apr-12 16:15 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Closed Resolution: Works For Me Bug Group: None Priority: 5 Submitted by: darose Assigned to : none Summary: ssl certificate verification broken in fetchmail 6.3.16 Details: As I indicated in a bug at the Arch Linux distro site (http://bugs.archlinux.org/task/19043) upgrading to FM 6.3.16 broke my mail fetch. Downgrading back to 6.3.14 fixes it. [darose@darsys12 ~]$ /usr/bin/fetchmail -v fetchmail: 6.3.16 querying darose.net (protocol POP3) at Sun 11 Apr 2010 10:41:11 AM EDT: poll started Trying to connect to 208.97.132.208/995...connected. fetchmail: Issuer Organization: New Dream Network, LLC fetchmail: Issuer CommonName: New Dream Network Certificate Authority fetchmail: Server CommonName: *.mail.dreamhost.com fetchmail: darose.net key fingerprint: 17:F7:F2:FF:4A:9D:C3:D3:2B:8A:E9:12:47:C4:A4:28 fetchmail: Server certificate verification error: unable to get local issuer certificate 139713097279144:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1056: fetchmail: SSL connection failed. fetchmail: socket error while fetching from da...@da...@darose.net fetchmail: 6.3.16 querying darose.net (protocol POP3) at Sun 11 Apr 2010 10:41:12 AM EDT: poll completed fetchmail: Query status=2 (SOCKET) fetchmail: normal termination, status 2 [darose@darsys12 ~]$ /usr/bin/fetchmail -v fetchmail: 6.3.14 querying darose.net (protocol POP3) at Sun 11 Apr 2010 10:40:43 AM EDT: poll started Trying to connect to 208.97.132.208/995...connected. fetchmail: Issuer Organization: New Dream Network, LLC fetchmail: Issuer CommonName: New Dream Network Certificate Authority fetchmail: Server CommonName: *.mail.dreamhost.com fetchmail: darose.net key fingerprint: 17:F7:F2:FF:4A:9D:C3:D3:2B:8A:E9:12:47:C4:A4:28 fetchmail: POP3< +OK Hello there. fetchmail: POP3> CAPA fetchmail: POP3< +OK Here's what I can do: fetchmail: POP3< STLS fetchmail: POP3< TOP fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 10 fetchmail: POP3< PIPELINING fetchmail: POP3< UIDL fetchmail: POP3< IMPLEMENTATION Courier Mail Server fetchmail: POP3< . fetchmail: POP3> USER da...@da... fetchmail: POP3< +OK Password required. fetchmail: POP3> PASS * fetchmail: POP3< +OK logged in. fetchmail: POP3> STAT fetchmail: POP3< +OK 0 0 fetchmail: No mail for da...@da... at darose.net fetchmail: POP3> QUIT fetchmail: POP3< +OK Bye-bye. fetchmail: 6.3.14 querying darose.net (protocol POP3) at Sun 11 Apr 2010 10:40:44 AM EDT: poll completed fetchmail: normal termination, status 1 My fetchmailrc is as follows: set postmaster "root" set bouncemail set no spambounce set properties "" poll darose.net via <my dreamhost mail server>.mail.dreamhost.com with proto POP3 user 'da...@da...' there with password '<my password>' is 'darose' here options fetchall ssl sslcertck sslcertpath /home/darose/certs And the certs directory contains dreamhost's "ndn" (New Dream Network) ssl cert: [darose@darsys12 .fetchmail]$ ls -l /home/darose/certs total 16 lrwxrwxrwx 1 darose users 10 Aug 1 2008 17a3f64c.0 -> ndn.ca.pem lrwxrwxrwx 1 darose users 19 Aug 1 2008 2bbe502b.0 -> mail.darose.net.pem -rw-r--r-- 1 darose users 1578 Aug 1 2008 mail.darose.net.pem -rw-r--r-- 1 darose users 2151 Aug 1 2008 ndn.ca.crt -rw-r--r-- 1 darose users 1546 Aug 1 2008 ndn.ca.der -rw-r--r-- 1 darose users 2151 Aug 1 2008 ndn.ca.pem Any ideas? Thanks! Follow-Ups: Date: 2010-Apr-12 17:10 By: m-a Comment: Please do not make up hostnames for SSL-related reports, otherwise they may be impossible to debug. This time, I could guess your hostname with a bit of Googling, and it works for me on openSUSE 11.2 and Cygwin 1.7. As pointers: Does fetchmail parse your rcfile properly (try fetchmail -Vv)? What type of file system (ext3, ext4, nfs, afs, cifs, coda, smbfs...) is your /home/darose... on? What OpenSSL version are you using? Are libssl or libcrypto linked statically or dynamically? Is LD_PRELOAD in effect? Here's the trace: <pre> $ wget -nv https://dreamhost.com/ca/ndn.ca.crt 2010-04-12 16:58:50 URL:https://dreamhost.com/ca/ndn.ca.crt [2151/2151] -> "ndn.ca.crt" [1] $ mv ndn.ca.crt ndn.ca.pem $ c_rehash . Doing . ndn.ca.pem => 17a3f64c.0 $ LC_ALL=C build/fetchmail -v --auth external --user nobody --sslcertpath /tmp --sslcertck --ssl -p pop3 a1.balanced.homie.mail.dreamhost.com fetchmail: 6.3.16 querying a1.balanced.homie.mail.dreamhost.com (protocol POP3) at Mon Apr 12 16:56:56 2010: poll started Trying to connect to 208.97.132.208/995...connected. fetchmail: Issuer Organization: New Dream Network, LLC fetchmail: Issuer CommonName: New Dream Network Certificate Authority fetchmail: Server CommonName: *.mail.dreamhost.com fetchmail: a1.balanced.homie.mail.dreamhost.com key fingerprint: 17:F7:F2:FF:4A:9D:C3:D3:2B:8A:E9:12:47:C4:A4:28 fetchmail: POP3< +OK Hello there. </pre> Looks ok, we get past the SSL negotiation successfully. The relevant diff between 6.3.14 and 6.3.16 is in socket.c adds OpenSSL_add_all_algorithms(), but I fail to see how it could possibly trigger an issue here. If it did, then it would be OpenSSL's fault anyways, not fetchmail's. relevant differences 6.3.14 -> 6.3.16 in socket.c: <pre> @@ -819,16 +814,16 @@ -int SSLOpen(int sock, char *mycert, char *mykey, char *myproto, int certck, cha r *certpath, +int SSLOpen(int sock, char *mycert, char *mykey, const char *myproto, int certc k, char *certpath, char *fingerprint, char *servercname, char *label, char **remotename) { struct stat randstat; int i; SSL_load_error_strings(); - SSLeay_add_ssl_algorithms(); /* synonym for SSL_library_init() */ - -#ifdef SSL_ENABLE + SSL_library_init(); + OpenSSL_add_all_algorithms(); /* see Debian Bug#576430 and manpage */ + if (stat("/dev/random", &randstat) && stat("/dev/urandom", &randstat)) { /* Neither /dev/random nor /dev/urandom are present, so add </pre> ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=17073&group_id=1824 |
