[racket] outgoing https requests with client certificate with plt 4.2.5

FYI, for anyone who finds this thread with Google...

PLT 4.2.5 "openssl" apparently *can* do outgoing client certificate 
authentication to *some* servers.  I am currently seeing a problem 
talking to Apache, however.

I might not be able to spend any more time on this, so if you find 
you're having trouble talking to Apache, here's where I left off...

At this point, I think that PLT is not handshaking successfully with an 
Apache in particular, yet PLT mistakenly believes that handshake was 
OK.  I think that the next debugging step is to find why "mzssl.ss" 
thinks handshaking succeeded.  Finding that might also find why the 
handshake failed (e.g., perhaps some OpenSSL default verify callback is 
doing the wrong thing for handshaking under the circumstances, yet 
effectively telling "mzssl.ss" that everything is OK).

(Ray Racine helpfully suggested trying "openssl s_server" with debugging 
info, and trying that was gratifying in that PLT worked with it, but 
unfortunately "s_server" working meant that its debugging info is not 
very helpful for debugging why Apache fails.  Before trying "s_server", 
tonight I spent some time comparing "mzssl.c"'s uses of OpenSSL to that 
"curl", "openssl s_client", and "ssltest.c", and occasionally looking 
into the OpenSSL source.  Unfortunately, all four clients use seemingly 
pertinent bits of OpenSSL differently to an extent such that comparing 
them to "mzssl.ss" has thus far been surprisingly unhelpful.)

(An oddity to note is that, when PLT is talking to "s_server", the state 
labeled "SSL_accept:SSLv3 flush data" in "s_server"'s debug info shows 
fragmentation like that I mentioned earlier about the decrypted protocol 
traces in Wireshark.  However, fragmentation is not shown earlier in the 
debugging info, during negotiation, so for now I'm assuming that this 
fragmentation is not the cause of the failure to handshake with Apache, 
and that it is benign.)

-- 
http://www.neilvandyke.org/