On Tue, Jan 18, 2000 at 01:12:58PM -0800, Jeremy Katz wrote:
> Actually, I have no clue why it was trying to connect to port 143 at
> the time. It is now connecting to 993, but saying it is unable to get
> certificate from peer.
Eh.. you didn't touch a thing but it just started working?
> strace output:
Thanks, it revealed the IP so I quickly made my own tests:
-----8<----------8<-----
~% openssl s_client -host 152.1.2.236 -port 993 -verify -debug
verify depth is 0
CONNECTED(00000003)
6666:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:203:
-----8<----------8<-----
Hmm.. so there's something wrong with SSL handshaking..
Now, disabling protocols one by one I got this:
-----8<----------8<-----
~% openssl s_client -host 152.1.2.236 -port 993 -verify -debug -no_tls1
verify depth is 0
CONNECTED(00000003)
depth=0 /C=US/ST=North Carolina/L=Raleigh/O=North Carolina State
[EMAIL PROTECTED]
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=North Carolina/L=Raleigh/O=North Carolina State
[EMAIL PROTECTED]
verify return:1
...
-----8<----------8<-----
Which means it should work fine if you just disable the TLS protocol.
There's no way to do this in mutt right now, so you're out of luck
unless you can persuade your server administrator to change their
configuration. Or you could try using stunnel or something, I think
they can be configured to disable some protocols.
Maybe we need to introduce a new variable allow disabling/enabling
certain SSL protocols, or even better, modify the connection logic to
notice unsupported protocols and try again without them. I'm not sure
if the latter is even possible. I was under the impression that
there's no harm in enabling all protocols and that if one isn't
supported, another on would be tried. Apparently, I was wrong.
--
Tommi Komulainen [EMAIL PROTECTED]
