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

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

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

> I've gone ahead and put together a preliminary patch, against the SVN code. 
> This implements a new keyword: "sslcommonname". (Forget my earlier 
> suggestion of "sslalternate"---I wasn't thinking straight when I made it :]
>
> The approach I took was basically to find all instances of 
> "sslfingerprint", and implement the new keyword similarly at each turn
> (which turned out to be quite easy). On the downside, you can only specify 
> one CommonName, whereas I had originally envisioned allowing many.

Well, there are string list functions inside fetchmail, and these can
help with the implementation. I wonder if that's useful though - that
would mean servers behind a load balancer use different common names.

> You'll notice that the critical bits are in driver.c, imap.c and pop3.c, 
> before and when the call to SSLOpen() is made. Everything else is 
> supporting boilerplate.
>
> Please let me know how this patch looks, and if it looks good, I'll flesh 
> it out (with deltas on the man page and documentation) for submission.

Looks good to me (I haven't applied and tested it though yet).

A tiny bit, the "cname" variables might better be renamed (perhaps to
"comname" or sslcommonname) to avoid someone (like myself) from assuming
it might have to do with the DNS CNAME resource record (canonical name).

Thanks for your work!

-- 
Matthias Andree