> 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.


[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 (

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,

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

Reply via email to