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...

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