All,
Some days...
I've been working with another individual,
<beldridg(_at_)best(_dot_)com>, to
try and track down why he could not get SSL Client Side certs to work
(gee, they've always worked for me :-) ) and just found the reason.
In driver.c the call to SSLOpen has the order of the cert and key
files backwards from the function itself in socket.c. I can't believe
that I actually did that or that it's been in there for sooo long (three
years?) without anyone noticing. :-/
Net result was that if you were using a combined cert and key
in a single file, it would work. If you had a separate key and cert,
it would fail (unless you specified them backwards. :-) ).
One line patch is attached below...
Eric: Please apply. Sorry about that.
Regards,
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw(_at_)WittsEnd(_dot_)com
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
diff -urN fetchmail-5.9.0.orig/driver.c fetchmail-5.9.0/driver.c
--- fetchmail-5.9.0.orig/driver.c Fri Aug 3 13:58:11 2001
+++ fetchmail-5.9.0/driver.c Mon Sep 17 14:06:24 2001
@@ -890,7 +890,7 @@
/* perform initial SSL handshake on open connection */
/* Note: We pass the realhost name over for certificate
verification. We may want to make this configurable */
- if (ctl->use_ssl &&
SSLOpen(mailserver_socket,ctl->sslkey,ctl->sslcert,ctl->sslproto,ctl->sslcertck,
+ if (ctl->use_ssl &&
SSLOpen(mailserver_socket,ctl->sslcert,ctl->sslkey,ctl->sslproto,ctl->sslcertck,
ctl->sslcertpath,ctl->sslfingerprint,realhost,ctl->server.pollname)
== -1)
{
report(stderr, _("SSL connection failed.\n"));