[fetchmail]Re: [fetchmail-users] SSL authentication problems with Gmail
Sebastian Tennant
sebyte@smolny.plus.com
Wed, 04 Jan 2006 21:03:16 +0000
--=-=-=
Matthias Andree <matthias.andree@gmx.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@gmail.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@gmail.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@gmail.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@gmail.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@gmail.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
--=-=-=
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=fetchmailrc
Content-Transfer-Encoding: base64
Content-Description: Debian's fetchmail init script (edited)
IyAtKi0gbW9kZTogc2hlbGwtc2NyaXB0IC0qLQojIChzZWJ5dGVkKQojIC9ldGMvZmV0Y2htYWls
cmMKCiMgfi8uZmV0Y2htYWlscmMgaXMgaWdub3JlZCB1bmxlc3MgZmV0Y2htYWlsIGlzIGNhbGxl
ZCBmcm9tIHRoZQojIGNvbW1hbmQgbGluZS4gIGZldGNobWFpbCBpcyBzdGFydGVkIGluIGRhZW1v
biBtb2RlIGJ5IGFuIGluaXQgc2NyaXB0CiMgaWYgKGFuZCBvbmx5IGlmKSAvZXRjL2ZldGNobWFp
bHJjIGlzIGZvdW5kLCBpcyBzeW50YWN0aWNhbGx5IGNvcnJlY3QsCiMgYW5kIGhhcyBhY2Nlc3Mg
bW9kZSBgLXJ3LS0tLS0tIGZldGNobWFpbCBtYWlsJy4KCiMgc2VlIHRoZSBmZXRjaG1haWwgbWFu
cGFnZSBmb3IgZGV0YWlsZWQgaW5zdHJ1Y3Rpb25zLgoKc2V0IGRhZW1vbiA2MDAKc2V0IHBvc3Rt
YXN0ZXIgc2VieXRlCnNldCBubyBib3VuY2VtYWlsCnNldCBubyBzcGFtYm91bmNlCgojIHVubGVz
cyBgbm8gc3lzbG9nJyBpcyBzZXQgZmV0Y2htYWlsIHdpbGwgbG9nIHRvICR2bG8vc3lzbG9nIEFO
RCAkdmxvL21haWwvCiNzZXQgbm8gc3lzbG9nCgpwb2xsIHBvcC5nbWFpbC5jb20gd2l0aCBwcm90
b2NvbCBwb3AzIHBvcnQgOTk1IAogICAgIHVzZXIgInNlYnl0ZUBnbWFpbC5jb20iIHBhc3MgImdt
YTFsNG1lIiBpcyAic2VieXRlIiBoZXJlCiAgICAgd2l0aCBvcHRpb25zIHNzbCBzc2xjZXJ0Y2sg
c3NsY2VydHBhdGggIi9ob21lL3NlYnl0ZS8uZ251cy5kL2NlcnRzIiBrZWVwCgojIyB0aGVzZSBl
eHRyYSBvcHRpb25zIHByb3ZlZCB1bm5lY2Vzc2FyeQoKCiMKIyB0aGUgZ29vZ2xlIGNlcnRpZmlj
YXRlL2hhc2ggaW4gfi8uZ251cy5kL2NlcnRzLyBpcyBvYnZpb3VzbHkgb25seSBuZWVkZWQKIyBp
biB0aGUgX2Fic2VuY2VfIG9mIGEgdGhhd3RlIGNlcnRpZmljYXRlLgoKIyB0byByZXN0YXJ0IGZl
dGNobWFpbCwgKG5lY2Vzc2FyeSBmb3IgY2hhbmdlcyB0byB0YWtlIGFmZmVjdCksCiMgcnVuIGAv
ZXRjL2luaXQuZC9mZXRjaG1haWwgcmVzdGFydCcKCiMgQXMgb2YgdmVyc2lvbiA2LjIuNS03IHRo
ZSBmZXRjaG1haWwgaW5pdCBzY3JpcHQgbm8gbG9uZ2VyIHN1cHBvcnRzIHJ1bm5pbmcKIyBmZXRj
aG1haWwgc3lzdGVtIHdpZGUgYXMgcm9vdCB1bmxlc3MgaW5zdHJ1Y3RlZCB0byBkbyBzbyBpbgoj
IC9ldGMvZGVmYXVsdC9mZXRjaG1haWwuICBTYWZlciB0byBydW4gYXMgdXNlciBgZmV0Y2htYWls
Jy4K
--=-=-=--