Re: [fetchmail-devel] Workaround for unavoidable SSL CommonName mismatch?

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

"Daniel Richard G." <sk...@iS...> writes:

> On Sun, 2006 Apr 23 22:16:07 +0200, Matthias Andree wrote:
>> 
>> Well, fetchmail is in fact talking to mail.mydomain.com, so allowing
>> certificates for other domains on the server wouldn't be the right thing
>> to do.
>
> There is no way for mail.mydomain.com to have an SSL certificate with 
> CN=mail.mydomain.com. Not unless I shell out for a dedicated IP address. 
> Alternate names are not a solution either, unless one wants to download a 
> certificate with 100000+ alternates :]

Well...

> I agree that webhost.com did a lousy job of setting up their SSL mail 
> services, but given that that's the current, unlikely-to-change-in-the- 
> near-future reality, the issue becomes fetchmail's flexibility in handling 
> a less-than-ideal server situation.

I'll ponder this a bit, and see if "aka" or "via" should be overloaded
or a new option be introduced. I usually prefer separate options because
sooner or later someone will find a use case where overloading a token
restricts flexibility again and the initial enthusiasum for saving yet
another token turns into frustration because existing documentation,
practice and configuration locks the software in to its former way of
overloading the token for quite a while.

Currently the expected name is the "via" name if given, otherwise the
poll name.

>> You can however obtain the server's certificate fingerprint (run
>> fetchmail with -v (in verbose mode)) and then use the sslfingerprint
>> option to suppress the warning. Fetchmail will then abort the connection
>> if the fingerprint does not match.
>
> That's what I'm doing for now, but I still get the "CommonName mismatch" 
> warnings. (Twice for every connection, in fact.) I want to get rid of 
> those, and I'd still like to be able to do full certificate checking 
> (modulo the specifically-configured exception for the CN).

Which indicates that you are running a version before 6.3.4. This
version fixed this particular issue (well, as long as "sslcertck" isn't
enabled, which would deliberately turn the CN mismatch into a fatal
socket errors anyways).

-- 
Matthias Andree