Re: [fetchmail-devel] Assorted minor bugs

[Brian C. <B.C...@po...>]

> *Shrug* I don't see how it's printed three times. It's printed once on
> my computer.

There's some more detailled output at
http://lists.ccil.org/pipermail/fetchmail-friends/2004-April/008516.html

Basically, each verify callback operation causes this warning to be shown,
and with fetchmail -v you get this in addition to the other verification
warning associated with that callback. So with fetchmail -v I get (snipped a
little):

fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
fetchmail: Warning: server certificate verification: unable to get local issuer certificate
fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
fetchmail: Warning: server certificate verification: certificate not trusted
fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
fetchmail: Warning: server certificate verification: unable to verify the first certificate

That's with 6.2.5, I've not tried your snapshot yet.

Now, if I run fetchmail without -v, then the intervening verification errors
are not shown, so I just see the CN mismatch errors three times. Perhaps you
only see them once because you have root certs installed in the correct
places, or maybe it's a difference in our versions of openssl.

> Anyways, I would not want to limit this warning to verbose
> or strict mode or similar, it's an important information and needs to be
> printed unconditionally.

Well, I disagree that this information is any more important than
"certificate not trusted" or "unable to verify signature" or the various
other errors that only fetchmail -v or fetchmail sslcertck will show.

In particular: fetchmail (without -v) will not generate any warning for a
self-signed certificate where the CN is correct. However, if you have a
valid signed certificate from a known CA, but the hostname does not match,
you get the warning (three times in my case).

Both are violations of the SSL trust model. In the latter case, you know
that the server admin did at least manage to persuade a known and trusted CA
to sign a certificate, albeit for a different hostname. Whereas, in the
first case you could be the subject of a man-in-the-middle attack, and you
get no warning at all.

That's why my preferred solution was to silence this message without -v or
sslcertck: because more serious messages are already silenced.

Regards,

Brian.