> 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/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 169.3.0) > 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) https://gist.github.com/anonymous/8f6533a755ae5c710c75 Initial connection is correct (line 10 - shows that it reads correct certificate), 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 (?). Thanks! Janusz -- 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