FS#19043 - [fetchmail] ssl certificate verification broken in fetchmail 6.3.16

Attached to Project: Arch Linux
Opened by David Rosenstrauch (darose) - Sunday, 11 April 2010, 14:50 GMT
Last edited by Pierre Schmitz (Pierre) - Tuesday, 13 April 2010, 04:38 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Pierre Schmitz (Pierre)
Aaron Griffin (phrakture)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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 darose@darose.net@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 darose@darose.net
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 darose@darose.net 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


Any ideas? Thanks!
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Tuesday, 13 April 2010, 04:38 GMT
Reason for closing:  None
Comment by Pierre Schmitz (Pierre) - Sunday, 11 April 2010, 15:26 GMT
It seems to work fine here (using tls and ssl on several hosts; it's imap though) Could you post your config? It looks like you are connecting to darose.net while the certificate is for *.mail.dreamhost.com.
Comment by David Rosenstrauch (darose) - Sunday, 11 April 2010, 22:26 GMT
darose.net is hosted at dreamhost, hence the use of mail.dreamhost.com.

My config 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 'darose@darose.net' there with password '<my password>' is 'darose' here options fetchall ssl sslcertck sslcertpath /home/darose/certs


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


Not sure why you're not seeing this on your end, but this is easily reproducible on my end by switching to v6.3.16, and goes away when I downgrade. So definitely *something* in the new release is causing it. Though it may also be that there's something unique about my configuration that's triggering the issue in the new version.

Any ideas?
Comment by Pierre Schmitz (Pierre) - Monday, 12 April 2010, 04:06 GMT
Try to add

sslproto TLS1

or just

ssl

Otherwise I would suggest to report that upstream to the fetchmail devs.
Comment by David Rosenstrauch (darose) - Monday, 12 April 2010, 14:09 GMT
It does say just "ssl". I'll try TLS1, and if no worky, I'll file upstream.
Comment by David Rosenstrauch (darose) - Monday, 12 April 2010, 14:39 GMT
Upstream bug filed:

http://developer.berlios.de/bugs/?func=detailbug&bug_id=17073&group_id=1824
Comment by Matthias Andree (mandree) - Monday, 12 April 2010, 16:44 GMT
As reported in the BerliOS tracker, this isn't a fetchmail bug.

David is using OpenSSL 1.0.0, and that changes the way the hashes are made, relative to earlier OpenSSL versions such as 0.9.8.

for 0.9.8, you get 17a3f64c.0 -> ndn.ca.pem

for 1.0.0, you get 05e36882.0 -> ndn.ca.pem instead


Note that OpenSSL 1.0.0's c_rehash doesn't build the PATH properly, so do this:

env PATH=/path/to/openssl1.0.0/bin:$PATH /path/to/openssl1.0.0/bin/c_rehash /home/darose/certs

A patch to fix c_rehash has been filed to OpenSSL's request tracker and is also attached. Note that the OpenSSL patch isn't sanctioned or reviewed in any way yet.
   openssl-1.0.0-fix-c_rehash.pa... (1.6 KiB)
Comment by Pierre Schmitz (Pierre) - Monday, 12 April 2010, 17:02 GMT
Oh sure, I overlooked that. The hashes were recreated during the ca-certificates update. But David seems to not use the system wider certs store, but put it somewhere in his home dir.

Not sure about this patch though; the openssl binary is already in $PATH (/usr/bin/openssl) and openssl 1.0.0 is the only available openssl version for Arch anyway. So "c_rehash /home/darose/certs" should do it. Or even better: put the needed certs into the system store and such things will be taken care of during updates; see "man update-ca-certificates"

Let me know if this issue has been resolved.
Comment by Matthias Andree (mandree) - Monday, 12 April 2010, 17:10 GMT
the patch would be needed on systems that install multiple OpenSSL versions in parallel - I wasn't sure if that was the case for David.
Comment by David Rosenstrauch (darose) - Monday, 12 April 2010, 18:18 GMT
Confirmed Pierre's solution. After performing "c_rehash /home/darose/certs", the upgraded fetchmail (v6.3.16) works correctly.

Bug can be closed.

Thanks for the help Matthias & Pierre!

Loading...