git - 连接中出现未知的 SSL 协议(protocol)错误

Question

我想将我的提交推送到 Bitbucket 存储库，但是发生了这个错误:

Fatal: unable to access
'https://myUsername@bitbucket.org/myUsername/myRepository.git/':
Unknown SSL protocol error in connection to bitbucket.org:443

Answer 1

您可以通过

获取更多信息

# Windows
set GIT_CURL_VERBOSE=1
set GIT_TRACE_PACKET=2

# Unix
export GIT_CURL_VERBOSE=1
export GIT_TRACE_PACKET=2

然后尝试 git push。

如果您有代理设置，请仔细检查。

注意:git 2.8(2016 年 3 月)添加了有关错误 35 的更多信息:

参见 commit 0054045 (2016 年 2 月 14 日)作者 Shawn Pearce (spearce) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit 97c49af ，2016 年 2 月 24 日)}

remote-curl: include curl_errorstr on SSL setup failures

For curl error 35 (CURLE_SSL_CONNECT_ERROR) users need the additional text stored in CURLOPT_ERRORBUFFER to debug why the connection did not start.
This is curl_errorstr inside of http.c, so include that in the message if it is non-empty.

---

另请查看 common causes for that message :

如果它以前可以工作，而今天不工作，则可能是 BitBucket 端的 SSL 私钥已经过期(见下文，原因 #3)，但这里似乎不是这种情况(证书有效期至 12/03/2014)。

---

目标站点不喜欢该协议(protocol)

Firing off a request like the following, results in the Unknown SSL Protocol error:

curl --sslv2 https://techstacks-tools.appspot.com/

Why? Well, in this case it is because the techstacks tools site does not support SSLv2, thus, generating the curl (35) error.

目标站点不喜欢密码

You could be trying to connect to the site using an ssl cipher that the site is configured to reject.
For example, anonymous ciphers are typically disabled on ssl-encrypted sites that are customer-facing. (Many of us set a blanket rejection policy on any SSL-encrypted web site—regardless of it's purpose.)
The following command string "can" also result in the curl (35) error:

curl --ciphers ADH-RC4-MD5 https://some_web_site.some_domain.com/

Unfortunately, the type of error response you can get from curl depends largely upon the ssl server. On some sites, you'll receive the Unknown SSL Protocol error but on my techstacks-tools site, I get:

curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Kudos to Google because this particular error is a bit more descriptive than the one my websites at work generate because this at least tells you that a ssl socket was started but because of handshake failures, the socket was never able to complete.

Try connecting to the site with a cipher that the site supports. Not sure which cipher to use? Well, let me introduce my cryptonark ssl cipher tester...

SSL 私钥已过期

I came across this one earlier today working with an old WebSeAL site.
In IBM GSKit, you can specify how long the private key password is valid. After reaching a certain date, you will still be able to get webseal started and listening on port 443 (or whatever you set your https-port value to) but you will not be able to successfully negotiate an SSL session.
In today's case, the old WebSEAL instance was using long-expired kdb file with a long expired private key password. Once replaced with the correct, more-up-to-date version, everything worked again.

重定向不当

Some ISP's and DNS providers like to intercept your failed DNS queries in order to redirect you to a search engine results-style page offering you alternative URLs or "Did you mean...?" counter-query results.
If you see an error like this:

 error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol, 

it could be due to you typing the hostname incorrectly or the hostname is not yet tabled in your DNS. You can verify that with a simple "host" or "nslookup".

---

注意(2015 年 8 月):Git 2.6+(2015 年第 3 季度)将允许明确指定 SSL 版本:

http: add support for specifying the SSL version

参见 commit 01861cb (2015 年 8 月 14 日)Elia Pinto (devzero2000) .
帮助:Eric Sunshine (sunshineco) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit ed070a4 ，2015 年 8 月 26 日)}

http.sslVersion

The SSL version to use when negotiating an SSL connection, if you want to force the default.
The available and default version depend on whether libcurl was built against NSS or OpenSSL and the particular configuration of the crypto library in use. Internally this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl documentation for more details on the format of this option and for the ssl version supported.
Actually the possible values of this option are:

• sslv2
• sslv3
• tlsv1
• tlsv1.0
• tlsv1.1
• tlsv1.2

Can be overridden by the 'GIT_SSL_VERSION' environment variable.
To force git to use libcurl's default ssl version and ignore any explicit http.sslversion option, set 'GIT_SSL_VERSION' to the empty string.