> 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. line: [36] * 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 session expiration: [64] * SSL re-using session ID [65] * SSL connection using RC4-SHA [66] * 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 (1.8.2.3) 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?) kind regards, Janusz p.s. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html