> What makes you suggest that's what's happening? Sure, if it would've sent no
> or the wrong host name it would probably have that effect.
 * Re-using existing connection! (#0) with host (nil)
> Any chance you can snoop on the network and the SSL handshake to see who's to
> blame? I can't but to think that is is a very common use case!
I was trying to verify this via command line curl, and GET/POST is working fine.
There is one thing that make me suspicious - this is that message about SSL
 * SSL re-using session ID
 * SSL connection using RC4-SHA
 * old SSL session ID is stale, removing
So, I've spent last few hours playing with different settings/builds etc.
I was using sources of curl (7.30.0) and git (220.127.116.11)
curl & git bult with default os-x's openssl (0.9.8) - failed
curl & git bult with '--with-darwin-ssl' + default openssl for git - failed
curl & git both bult with newest openssl (1.0.1e):
error: SSL certificate problem: self signed certificate in certificate chain
while accessing https://....
so it looks promising, I've set GIT_SSL_CAPATH (because bundle config is not
supported in git - this is a good feature request)
and.. t looks like it is working…
first and second attempt was to correct SNI host!
So, the question is still why it is not working with openssl 0.9.8r - this
version supports SNI by default.
This looks like an error in openssl (maybe: Only allow one SGC handshake
restart for SSL/TLS.)
Now is the question, shall this be handled by curl or left alone?
(handling older version of openssl, and force new ssl session?)
I've tested cur built with polarssl - works and gnutls - works too...
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html