[fetchmail]Re: [fetchmail-users] SSL authentication problems with Gmail

Matthias Andree <matthias(_dot_)andree(_at_)gmx(_dot_)de> wrote:

> > > Looks like it never talks to the POP server.  Can you drop the "port
> > > 995" and "sslcertck" options from your fetchmailrc and see what you
> > > get.
> > Removed these lines and it works.  Thanks to everyone who helped.
> Well, I checked the source code and found no code path where SSL
> certificate verification would fail without leaving log messages, such
> as 1. the actual error and 2. "SSL connection failed".
>
> POP3 was configured explicitly, so "port 995" forth or back doesn't make
> a difference either -- removing this option can only make things worse,
> not better.
>
> Remains the question after sslcertck -- it will log trouble, too, EXCEPT
> if a certificate at greater depth causes a preverification failure
> without setting the error code in the X.509 context variables (and we'd
> still get "SSL connection failed" in this case).
>
> It appears as though the server dropped the connection after the SSL
> negotiation and before the greeting, or that your log information is
> incomplete.  Your logging appears to be from syslog, so could you post
> your syslog.conf or syslog-ng.conf (whichever you're *actually* using)?
>
> Do you get more detailed logging with "fetchmail --nosyslog -vv -N -d0
> --sslcertck --port 995"? Can you try running this and see if you still
> get socket errors and if so, which errors they print?
OK, with the following config:

  poll pop.gmail.com with protocol pop3
       user "sebyte(_at_)gmail(_dot_)com" pass "xxxxxxx" is "sebyte" here
       with options ssl keep

The command (exactly as typed) produces the following:

  fetchmail: 6.3.1 querying pop.gmail.com (protocol POP3) at Wed Jan  4 
20:17:30 2006: poll started
  fetchmail: pop.gmail.com key fingerprint: 
59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4
  fetchmail: POP3< +OK Gpop e14pf314923qbe ready.
  fetchmail: POP3> CAPA
  fetchmail: POP3< +OK Capability list follows
  fetchmail: POP3< USER
  fetchmail: POP3< RESP-CODES
  fetchmail: POP3< EXPIRE 0
  fetchmail: POP3< LOGIN-DELAY 300
  fetchmail: POP3< X-GOOGLE-VERHOEVEN
  fetchmail: POP3< .
  fetchmail: POP3> USER sebyte(_at_)gmail(_dot_)com
  fetchmail: POP3< +OK send PASS
  fetchmail: POP3> PASS *
  fetchmail: POP3< +OK Welcome.
  fetchmail: selecting or re-polling default folder
  fetchmail: POP3> STAT
  fetchmail: POP3< +OK 0 0
  fetchmail: No mail for sebyte(_at_)gmail(_dot_)com at pop.gmail.com
  fetchmail: POP3> QUIT
  fetchmail: POP3< +OK Farewell.
  fetchmail: 6.3.1 querying pop.gmail.com (protocol POP3) at Wed Jan  4 
20:17:34 2006: poll completed
  fetchmail: not swapping UID lists, no UIDs seen this query
  fetchmail: Query status=1 (NOMAIL)
  fetchmail: Deleting fetchids file.
  fetchmail: normal termination, status 1
  fetchmail: Deleting fetchids file.

Like I said... it works, and if I run this command:

  $ fetchmail --nosyslog -vv -N -d0

 with this config:

  poll pop.gmail.com with protocol pop3 port 995
       user "sebyte(_at_)gmail(_dot_)com" pass "xxxxx" is "sebyte" here
       with options ssl sslcertck keep

 it runs equally well, producing exactly the same output.

However, when I run:

  $ fetchmail --nosyslog -vv -N -d0

 with the added option; sslcertpath "/home/sebyte/.gnus.d/certs" in
 the config, we get the same error as before, but this time we also get
 the useful error-logging you're expecting Mathias:

  fetchmail: 6.3.1 querying pop.gmail.com (protocol POP3) at Wed Jan  4 
20:30:40 2006: poll started
  fetchmail: pop.gmail.com key fingerprint: 
59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4
  fetchmail: Server certificate verification error: unable to get local issuer 
certificate
  25424:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate 
verify failed:s3_clnt.c:894:
  fetchmail: SSL connection failed.
  fetchmail: socket error while fetching from 
sebyte(_at_)gmail(_dot_)com@pop.gmail.com
  fetchmail: 6.3.1 querying pop.gmail.com (protocol POP3) at Wed Jan  4 
20:30:40 2006: poll completed
  fetchmail: Query status=2 (SOCKET)
  fetchmail: Deleting fetchids file.
  fetchmail: normal termination, status 2
  fetchmail: Deleting fetchids file.

So what does this tell us?

Debian ships fetchmail with an init script for
starting/stopping/restarting fetchmail in daemon mode.  I've been
using this to pass command line options and restart fetchmail each
time I've edited the site-wide config file, and then copied the
output from my syslog... that is until now.

Perhaps this has exposed a slight difference in logging behaviour
between daemon mode and single instance mode.  It would be nice if
something positive comes out of this escapade!  I've attached the init
script so you can check it yourself, but the fact remains, no matter
how many `-v's I passed to fetchmail in daemon mode, it never wrote
the detail to syslog that was so sorely missing.

Personally speaking, I wish I could get my hands on the guy who wrote
`the guide' to using fetchmail with gmail, that set me on this wild
goose chase in the first place.  It's only *too* clear to me now that
the Thawte certificate is all that's needed, and if you have Debian's
`ca-certificates' package installed, there's nothing more that needs
to be done.  Maybe, in the absence of the Thawte certificate, you can
grab Google's own certificate and authenticate that way, but I am not
going to the guy to find out!

sdt

fetchmailrc
Description: Debian's fetchmail init script (edited)