> It does. git uses libcurl for the HTTPS parts and it has support SNI for a 
> long time, assuming you built libcurl with a TLS library that handles it.
> Which libcurl version and SSL backend is this? (curl -V usually tells)
$ curl -V
curl 7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtsp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz 

$ otool -L /usr/local/bin/git
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, 
current version 1.0.0)
/usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, 
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 

> If you made it working by disabling certificate verification then it sounds 
> as 
> if SNI might still have worked and the problem was rahter something else, as 
> without SNI you can't do name-based virtual hosting over HTTPS - but perhaps 
> you wanted to communicate with the "default" server on that IP?

here is a log (with GIT_CURL_VERBOSE=1)


Initial connection is correct (line 10 - shows that it reads correct 
 but then subsequent call to the server (line 68) shows that the defat server 
certificate is used.

It looks like the second call was without hostname (?).


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