它为我工作，只需运行以下命令

git config --global http.sslVerify false

它将打开一个git凭据窗口，提供您的凭据。第一次只有它问

您可以像这样添加自签名证书，然后再按…

git config --global http.sslCAInfo "C:\Program Files\Git\usr\ssl\cert.pem"

它为我工作，只需运行以下命令

git config --global http.sslVerify false

它将打开一个git凭据窗口，提供您的凭据。第一次只有它问

检查防病毒和防火墙设置。

从一天到另一天，git不再工作了。根据上面的描述，我发现卡巴斯基在中间放置了一个自签名的反病毒个人根证书。按照上面的说明，我没有设法让Git接受该证书。我放弃了。对我来说有用的是禁用扫描加密连接的功能。

卡巴斯基开放 设置>附加>网络>不扫描加密连接

在此之后，git再次启用sslVerify。

请注意。这对我来说仍然不满意，因为我想让我的反病毒功能激活。在高级设置中，卡巴斯基显示了一个不能使用该功能的网站列表。Github不在其中。我会在卡巴斯基论坛上查的。似乎有一些话题，例如。 https://forum.kaspersky.com/index.php?/topic/395220-kis-interfering-with-git/&tab=comments#comment-2801211

在.gitconfig文件中，您可以添加以下给定值，以使自签名证书可接受

sslCAInfo = /home/XXXX/abc.crt

在使用sslKey或sslCert使用一行程序时要小心，如Josh Peak的回答所示:

git clone -c http.sslCAPath="/path/to/selfCA" \
  -c http.sslCAInfo="/path/to/selfCA/self-signed-certificate.crt" \
  -c http.sslVerify=1 \
  -c http.sslCert="/path/to/privatekey/myprivatecert.pem" \
  -c http.sslCertPasswordProtected=0 \
https://mygit.server.com/projects/myproject.git myproject

只有Git 2.14.x/2.15(2015年Q3)能够正确地解释~username/mykey这样的路径(同时它仍然可以解释/path/to/privatekey这样的绝对路径)。

参见Junio C Hamano (gitster)提交的8d15496(2017年7月20日)。 资助人:查尔斯·贝利(hashpling)。 (由Junio C Hamano合并- gitster -在commit 17b1e1d, 2017年8月11日)

http.c: http.sslcert and http.sslkey are both pathnames Back when the modern http_options() codepath was created to parse various http.* options at 29508e1 ("Isolate shared HTTP request functionality", 2005-11-18, Git 0.99.9k), and then later was corrected for interation between the multiple configuration files in 7059cd9 ("http_init(): Fix config file parsing", 2009-03-09, Git 1.6.3-rc0), we parsed configuration variables like http.sslkey, http.sslcert as plain vanilla strings, because git_config_pathname() that understands "~[username]/" prefix did not exist. Later, we converted some of them (namely, http.sslCAPath and http.sslCAInfo) to use the function, and added variables like http.cookeyFile http.pinnedpubkey to use the function from the beginning. Because of that, these variables all understand "~[username]/" prefix. Make the remaining two variables, http.sslcert and http.sslkey, also aware of the convention, as they are both clearly pathnames to files.