[fetchmail]SSL authentication problems with Gmail

Matthias Andree matthias.andree@gmx.de
Fri, 16 Dec 2005 01:03:05 +0100


Sebastian Tennant <sebyte@smolny.plus.com> writes:

> The relevant section of my /etc/fetchmailrc reads as follows:
>
>   poll "pop.googlemail.com" with protocol pop3 port 995
>         user "sebyte" pass "xxxxxxx" is "sebyte" here
>         options ssl sslcertck sslcertpath "/home/sebyte/.gnus.d/certs"
>         keep
>
>   total 8
>   lrwxrwxrwx  1 sebyte adm   10 Dec 14 23:06 ddc328ff.0 -> thwate.pem
>   lrwxrwxrwx  1 sebyte adm   14 Dec 14 23:06 e5b84c7a.0 -> googlemail.pem
>   -rw-rw-r--  1 sebyte adm 1223 Dec 14 23:06 googlemail.pem
>   -rw-rw-r--  1 sebyte adm 1126 Dec 14 23:06 thwate.pem

Appears ok.

> I am getting the following log output:
>
>   fetchmail[3917]: 6.2.5.4 querying pop.googlemail.com (protocol POP3) at Thu \
>                    Dec 15 09:26:07 2005: poll started
>   fetchmail[3917]: Issuer Organization: Thawte Consulting cc 
>   fetchmail[3917]: Issuer CommonName: Thawte Premium Server CA 
>   fetchmail[3917]: Server CommonName: pop.googlemail.com 
>   fetchmail[3917]: pop.googlemail.com key fingerprint: \
>                    46:8B:6C:F4:3E:4C:56:29:83:54:2C:37:42:F1:67:80
>   fetchmail[3917]: 6.2.5.4 querying pop.googlemail.com (protocol POP3) at Thu \
>                    Dec 15 09:26:08 2005: poll completed
>   fetchmail[3917]: Query status=3 (AUTHFAIL) 
>   fetchmail[3917]: sleeping at Thu Dec 15 11:36:13 2005 

Hm. Does another "-v" provide detail?

Does fetchmail 6.3.0 or 6.3.1-pre1 work for you?  See

http://fetchmail.berlios.de/              for 6.3.0

http://home.pages.de/~mandree/fetchmail/  for 6.3.1-pre1

> I haven't got my password wrong so presumably the problem lies with the
> certificates I've generated.  Is there a way to check these?  The instructions
> in the `Postfix tutorial' above suggest using the following command:
>
>   $ openssl s_client -connect pop.googlemail.com:995 -CApath \
>             /home/sebyte/.gnus.d/certs
>
> but in my experience, it says:
>
>   "... verify return code: 0 (ok)"
>
> whether I specify `/home/sebyte/.gnus.d/certs' as the CApath, or `rhubarb'!

Interesting, I get (with OpenSSL 0.9.7g 11 Apr 2005):

CONNECTED(00000003)
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=pop.googlemail.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=pop.googlemail.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=pop.googlemail.com
verify error:num=21:unable to verify the first certificate
verify return:1
...

Is another copy of the google root certificate in /etc/ssl/certs (or
whatever else the SSL default path for certificates is on your system)?
AFAIR -CApath just adds to the path without removing the former path
components.

-- 
Matthias Andree