在使用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.

你可以将GIT_SSL_NO_VERIFY设置为true:

GIT_SSL_NO_VERIFY=true git clone https://example.com/path/to/git

或者配置Git不验证命令行上的连接:

git -c http.sslVerify=false clone https://example.com/path/to/git

请注意，如果您不验证SSL/TLS证书，那么您很容易受到MitM攻击。

I'm not a huge fan of the [EDIT: original versions of the] existing answers, because disabling security checks should be a last resort, not the first solution offered. Even though you cannot trust self-signed certificates on first receipt without some additional method of verification, using the certificate for subsequent git operations at least makes life a lot harder for attacks which only occur after you have downloaded the certificate. In other words, if the certificate you downloaded is genuine, then you're good from that point onwards. In contrast, if you simply disable verification then you are wide open to any kind of man-in-the-middle attack at any point.

举一个具体的例子:著名的repo.or.cz存储库提供了一个自签名证书。我可以下载这个文件，把它放在/etc/ssl/certs这样的地方，然后做:

# Initial clone
GIT_SSL_CAINFO=/etc/ssl/certs/rorcz_root_cert.pem \
    git clone https://repo.or.cz/org-mode.git

# Ensure all future interactions with origin remote also work
cd org-mode
git config http.sslCAInfo /etc/ssl/certs/rorcz_root_cert.pem

注意，在这里使用本地git配置(即不使用——global)意味着这个自签名证书只对这个特定的存储库受信任，这很好。它也比使用GIT_SSL_CAPATH更好，因为它消除了git通过不同的证书颁发机构进行验证的风险，这种风险可能会受到损害。

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

sslCAInfo = /home/XXXX/abc.crt

在Windows上，这对我来说很管用:

将自签名证书的内容添加到ca-bundle文件的末尾。包括-----BEGIN CERTIFICATE-----和-----END CERTIFICATE-----行

ca-bundle文件的位置通常是C:\Program Files\Git\mingw64\ssl\certs

然后，将ca-bundle文件的路径添加到全局git配置中。下面的命令可以做到这一点:git config——global http。sslCAInfo "C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt"

注意:路径依赖于ca-bundle文件的本地路径!

Git自签名证书配置

博士tl;

永远不要禁用所有SSL验证! 这造成了一种糟糕的安全文化。不要成为那样的人。

您需要的配置键是:

http。sslverify -始终为真。见上注。

这些用于配置您信任的主机证书

http.sslCAPath http.sslCAInfo

它们用于配置您的证书以响应SSL挑战。

http.sslCert http.sslCertPasswordProtected

选择性地将上述设置应用于特定主机。

http。< url >。*

自签名证书颁发机构的全局.gitconfig

为了我自己和我的同事，本文介绍了如何在不禁用sslVerify的情况下使自签名证书工作。编辑你的.gitconfig，使用gitconfig——global -e添加以下内容:

# Specify the scheme and host as a 'context' that only these settings apply
# Must use Git v1.8.5+ for these contexts to work
[credential "https://your.domain.com"]
  username = user.name

  # Uncomment the credential helper that applies to your platform
  # Windows
  # helper = manager

  # OSX
  # helper = osxkeychain

  # Linux (in-memory credential helper)
  # helper = cache

  # Linux (permanent storage credential helper)
  # https://askubuntu.com/a/776335/491772

# Specify the scheme and host as a 'context' that only these settings apply 
# Must use Git v1.8.5+ for these contexts to work
[http "https://your.domain.com"]
  ##################################
  # Self Signed Server Certificate #
  ##################################

  # MUST be PEM format
  # Some situations require both the CAPath AND CAInfo 
  sslCAInfo = /path/to/selfCA/self-signed-certificate.crt
  sslCAPath = /path/to/selfCA/
  sslVerify = true

  ###########################################
  # Private Key and Certificate information #
  ###########################################

  # Must be PEM format and include BEGIN CERTIFICATE / END CERTIFICATE, 
  # not just the BEGIN PRIVATE KEY / END PRIVATE KEY for Git to recognise it.
  sslCert = /path/to/privatekey/myprivatecert.pem

  # Even if your PEM file is password protected, set this to false.
  # Setting this to true always asks for a password even if you don't have one.
  # When you do have a password, even with this set to false it will prompt anyhow. 
  sslCertPasswordProtected = 0

引用:

Git凭证 Git凭据存储 使用Gnome Keyring作为凭证存储 Git配置http.<url>。* Git v1.8.5支持

在克隆git时指定配置

如果你需要在每次回购的基础上应用它，文档告诉你只需要在你的回购目录中运行git config——local。当你还没有在本地克隆回购时，这是没有用的，不是吗?

你可以做全局->本地hokey-pokey通过设置你的全局配置，然后复制这些设置到你的本地回购配置一旦克隆…

或者，你可以在git克隆时指定配置命令，这些命令在目标repo克隆后应用到目标repo。

# Declare variables to make clone command less verbose     
OUR_CA_PATH=/path/to/selfCA/
OUR_CA_FILE=$OUR_CA_PATH/self-signed-certificate.crt
MY_PEM_FILE=/path/to/privatekey/myprivatecert.pem
SELF_SIGN_CONFIG="-c http.sslCAPath=$OUR_CA_PATH -c http.sslCAInfo=$OUR_CA_FILE -c http.sslVerify=1 -c http.sslCert=$MY_PEM_FILE -c http.sslCertPasswordProtected=0"

# With this environment variable defined it makes subsequent clones easier if you need to pull down multiple repos.
git clone $SELF_SIGN_CONFIG https://mygit.server.com/projects/myproject.git myproject/

一个衬套

编辑:请参阅VonC的回答，其中指出了关于从2.14.x/2.15到这一行的特定git版本的绝对路径和相对路径的警告

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/

CentOS无法加载客户端密钥

如果你在CentOS上尝试这个，你的。pem文件会给你

unable to load client key: "-8178 (SEC_ERROR_BAD_KEY)"

然后你会想要这个StackOverflow关于curl如何使用NSS而不是Open SSL的答案。

你会想要从source重建curl:

git clone http://github.com/curl/curl.git curl/
cd curl/
# Need these for ./buildconf
yum install autoconf automake libtool m4 nroff perl -y
#Need these for ./configure
yum install openssl-devel openldap-devel libssh2-devel -y

./buildconf
su # Switch to super user to install into /usr/bin/curl
./configure --with-openssl --with-ldap --with-libssh2 --prefix=/usr/
make
make install

重新启动计算机，因为libcurl仍然作为共享库存在于内存中

Python, pip和conda

相关:如何将自定义CA根证书添加到Windows中pip使用的CA存储?