fetchmail-users

[fetchmail-users] CommonName mismatch after fetchmail upgrade

[thomas <tho...@gm...>]

Hello,

I have upgraded to fetchmail "6.3.6+NTLM+SDPS+SSL+NLS" (the one
shipped with Debian Etch). My setup always worked sofar, but since I
get the following error :

fetchmail: 6.3.6 querying pop.myuniversity.tld (protocol POP3) at sam
17 fév 2007 21:40:46 CET: poll started
Trying to connect to 194.254.137.9/110...connected.
fetchmail: POP3< +OK POP3  Groupe ESSEC <792...@my...d>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK capability list follows
fetchmail: POP3< SASL LOGIN PLAIN CRAM-MD5 DIGEST-MD5 MSN
fetchmail: POP3< STLS
fetchmail: POP3< LAST
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< PIPELINING
fetchmail: POP3< UIDL
fetchmail: POP3< IMPLEMENTATION CommuniGatePro
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK start TLS negotiation
fetchmail: Issuer Organization: Stalker Software, Inc.
fetchmail: Issuer CommonName: stalker.com
fetchmail: Server CommonName: myuniversity.tld
fetchmail: Server CommonName mismatch: myuniversity.tld != pop.myuniversity.tld
fetchmail: pop.myuniversity.tld key fingerprint:
17:A5:89:D2:05:6F:41:6B:32:4C:9E:14:78:02:59:B6
fetchmail: Server certificate verification error: unable to get local
issuer certificate
fetchmail: Server certificate verification error: certificate not trusted
fetchmail: Server certificate verification error: unable to verify the
first certificate
fetchmail: POP3> CAPA
fetchmail: POP3< +OK capability list follows
fetchmail: POP3< SASL LOGIN PLAIN CRAM-MD5 DIGEST-MD5 MSN
fetchmail: POP3< LAST
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< PIPELINING
fetchmail: POP3< UIDL
fetchmail: POP3< IMPLEMENTATION CommuniGatePro
fetchmail: POP3< .
fetchmail: pop.myuniversity.tld: upgrade to TLS succeeded.
fetchmail: POP3> USER MYLOGIN
fetchmail: POP3< +OK please send the PASS
fetchmail: POP3> PASS *
fetchmail: POP3< -ERR secure access to this account is disabled
fetchmail: secure access to this account is disabled
fetchmail: Authorization failure on MY...@po...d
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Connection closed
fetchmail: 6.3.6 querying pop.myuniversity.tld (protocol POP3) at sam
17 fév 2007 21:40:47 CET: poll completed
fetchmail: Query status=3 (AUTHFAIL)

Maybe the certificate of my university is wrong, but the old version
of fetchmail had no problem to fetch the emails, so there must be a
workaround.

Thanks for the help
Thomas

Re: [fetchmail-users] CommonName mismatch after fetchmail upgrade

[Rob M. <rob...@gm...>]

On 2/17/07, thomas <tho...@gm...> wrote:
> Hello,
>
> I have upgraded to fetchmail "6.3.6+NTLM+SDPS+SSL+NLS" (the one
> shipped with Debian Etch). My setup always worked sofar, but since I
> get the following error :
>
> fetchmail: 6.3.6 querying pop.myuniversity.tld (protocol POP3) at sam
> 17 fév 2007 21:40:46 CET: poll started
<---SNIP--->
> fetchmail: POP3< +OK start TLS negotiation
> fetchmail: Issuer Organization: Stalker Software, Inc.
> fetchmail: Issuer CommonName: stalker.com
> fetchmail: Server CommonName: myuniversity.tld
> fetchmail: Server CommonName mismatch: myuniversity.tld != pop.myuniversity.tld
> fetchmail: pop.myuniversity.tld key fingerprint:
> 17:A5:89:D2:05:6F:41:6B:32:4C:9E:14:78:02:59:B6
> fetchmail: Server certificate verification error: unable to get local
> issuer certificate
> fetchmail: Server certificate verification error: certificate not trusted
> fetchmail: Server certificate verification error: unable to verify the
> first certificate
> fetchmail: pop.myuniversity.tld: upgrade to TLS succeeded.
> fetchmail: POP3> USER MYLOGIN
> fetchmail: POP3< +OK please send the PASS
> fetchmail: POP3> PASS *
> fetchmail: POP3< -ERR secure access to this account is disabled
> fetchmail: secure access to this account is disabled
<----SNIP--->
> Maybe the certificate of my university is wrong, but the old version
> of fetchmail had no problem to fetch the emails, so there must be a
> workaround.

The "old version" (you don't say which, but I suspect a pretty old
one) obviously didn't attempt to support TLS.  Simply disable TLS:

http://www.fetchmail.info/fetchmail-FAQ.html#K6

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] CommonName mismatch after fetchmail upgrade

[thomas <tho...@gm...>]

2007/2/17, Rob MacGregor <rob...@gm...>:
> > Maybe the certificate of my university is wrong, but the old version
> > of fetchmail had no problem to fetch the emails, so there must be a
> > workaround.
>
> The "old version" (you don't say which, but I suspect a pretty old
> one) obviously didn't attempt to support TLS.  Simply disable TLS:

Thanks a lot for your quick answer Rob, it works now.

I think the "old version" was 6.3.4-7. About the following version
shipped with Debian etch (6.3.6-rc3-1), I can read the following in
the distro-specific changelog:

fetchmail 6.3.5 and older had no way to enforce TLS. With those older
versions, TLS was always opportunistic, but fetchmail would happily
transmit the password in cleartext if STARTTLS failed. [...]
Configurations using --ssl --sslcertck however have been safe.

I think this is the reason why fetching emails worked until the
upgrade to 6.3.6. Anyway, problem fixed, re-thanks.

Thomas

Re: [fetchmail-users] CommonName mismatch after fetchmail upgrade

[Matthias A. <mat...@gm...>]

thomas <tho...@gm...> writes:

> Hello,
>
> I have upgraded to fetchmail "6.3.6+NTLM+SDPS+SSL+NLS" (the one
> shipped with Debian Etch). My setup always worked sofar, but since I
> get the following error :
> fetchmail: pop.myuniversity.tld: upgrade to TLS succeeded.
> fetchmail: POP3> USER MYLOGIN
> fetchmail: POP3< +OK please send the PASS
> fetchmail: POP3> PASS *
> fetchmail: POP3< -ERR secure access to this account is disabled
> fetchmail: secure access to this account is disabled
> fetchmail: Authorization failure on MY...@po...d

That is the actual issue here, not the mismatched TLS cert'.

JFTR: Fetchmail 6.3.6 does not (and 6.3.7) will not break the connection
just because of the mismatch, unless you request so (which means
--sslcertck). Future versions (6.4.X or something later) may however
make sslcertck the default.

Fetchmail has been sharing passwords with man-in-the-middle attackers in
its default configuration for too long and the new paradigm of a future
version will be that explicit configuration is required to allow
unsecure connections, rather than requiring explicit configuration to
secure connections.

And more for the records: If you want to disable TLS, first sell
myuniversity.tld's NOC a clue so they allow encrypted connections for
everyone, then set

            sslproto ''

in the run control file for your account until they've fixed their
servers or bought reasonable hardware to run their software on.

-- 
Matthias Andree