我怎样才能让git接受一个自签名的证书?

使用Git,有没有办法告诉它接受一个自签名的证书?

我正在使用https服务器托pipe一个git服务器,但现在证书是自签名的。

当我尝试第一次在那里创build回购时:

git push origin master -f 

我得到的错误:

 error: Cannot access URL https://the server/git.aspx/PocketReferences/, return code 22 fatal: git-http-push failed 

永久接受特定的证书

试试http.sslCAPathhttp.sslCAInfo 。 亚当斯皮尔斯的回答给出了一些很好的例子。 这是这个问题最安全的解决scheme。

为单个git命令禁用TLS / SSLvalidation

尝试传递-c与适当的configurationvariables,或使用Flow的答案 :

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

禁用特定存储库的SSLvalidation

如果存储库完全在您的控制之下,您可以尝试:

 git config http.sslVerify false 

在全球范围内禁用TLS(/ SSL)证书validation是非常不安全的做法。 不要这样做。 不要使用--global修饰符发出上述命令。


git有相当多的SSLconfiguration选项。 从git config的手册页:

 http.sslVerify Whether to verify the SSL certificate when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_NO_VERIFY environment variable. http.sslCAInfo File containing the certificates to verify the peer with when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_CAINFO environment variable. http.sslCAPath Path containing files with the CA certificates to verify the peer with when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_CAPATH environment variable. 

其他一些有用的SSLconfiguration选项:

 http.sslCert File containing the SSL certificate when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_CERT environment variable. http.sslKey File containing the SSL private key when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_KEY environment variable. http.sslCertPasswordProtected Enable git's password prompt for the SSL certificate. Otherwise OpenSSL will prompt the user, possibly many times, if the certificate or private key is encrypted. Can be overridden by the GIT_SSL_CERT_PASSWORD_PROTECTED environment variable. 

您可以将GIT_SSL_NO_VERIFY设置为true

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

或者可以configurationGit不要在命令行上validation连接:

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

请注意,如果您不validationSSL / TLS证书,那么您很容易受到MitM攻击

我不是[编辑:原始版本]现有答案的巨大粉丝,因为禁用安全检查应该是最后的手段,而不是第一个解决scheme。 即使你不能相信第一张收据上的自签名证书,而没有一些额外的validation方法,那么使用证书进行后续的git操作,至less会让你的生活更加困难,只有你下载证书之后才会发生攻击。 换句话说,如果你下载的证书真的,那么从这一点开始你就很好。 相比之下,如果您只是停用validation,那么您随时都可能面对任何一种中间人攻击。

举一个具体的例子:着名的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 config (即不使用 – --global )意味着这个自签名证书只是信任这个特定的存储库,这是很好的。 它比使用GIT_SSL_CAPATH更好,因为它消除了git通过可能被泄露的不同证书颁发机构进行validation的风险。

我一直遇到这个问题,所以写了一个脚本从服务器上下载自签名证书,并将其安装到〜/ .gitcerts,然后更新git-config指向这些证书。 它存储在全局configuration中,所以你只需要每个远程运行一次。

https://github.com/iwonbigbro/tools/blob/master/bin/git-remote-install-cert.sh

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

为了我自己和同事的缘故,我们设法让自签名证书在不禁用sslVerify情况下工作。 编辑你的.gitconfig使用git config --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 Config http。<url>。*从Git v1.8.5支持

git clone -ing时指定configuration

如果你需要在回购的基础上应用它,文档告诉你只要在你的repo目录下运行git config --local 。 那么,当你没有得到本地克隆的回购没有用,现在呢?

你可以通过设置全局configuration来完成global -> local hokey-pokey,然后将这些设置复制到你的本地repoconfiguration中

或者你可以做的是在git clone上指定一个configuration命令,一旦被克隆就可以应用到目标回购。

 # 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/ 

一个class轮

编辑:请参阅VonC的答案 ,指出了从2.14.x / 2.15到这个class轮的特定git版本的绝对和相对path的警告

 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 unable to load client key

如果你在CentOS上试用这个,你的.pem文件正在给你

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

那么你会希望这个StackOverflow的答案关于curl如何使用NSS而不是Open SSL。

你会想要从源代码重buildcurl

 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仍然在内存中作为共享库重新启动计算机

在使用sslKey或sslCert使用一个class轮时要小心,就像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年第三季度)能够正确解释像~username/mykey这样的path(虽然它仍然可以解释像/path/to/privatekey这样的绝对path)。

见Junio C gitstergitster )的 提交8d15496 (2017年7月20日) 。
帮助: Charles Bailey( hashpling ) 。
(由Junio C gitster合并- gitster -在2017年8月11日gitster 提交 )

http.chttp.sslcerthttp.sslkey都是path名

当现代的http_options()代码path被创build来parsing29508e1的各种http。*选项(“隔离共享的HTTP请求function”,2005-11-18,Git 0.99.9k)时,后来纠正了多重在configuration文件7059cd9 (“ http_init() :修复configuration文件parsing”,2009-03-09,Git 1.6.3-rc0)中,我们将configurationvariables像http.sslkeyhttp.sslcert一样parsing为普通的vanillastring,因为git_config_pathname()理解“ ~[username]/ ”前缀不存在。

后来,我们将其中的一些(即http.sslCAPathhttp.sslCAInfo )转换为使用该函数,并添加了像http.cookeyFile http.pinnedpubkey这样的variableshttp.cookeyFile http.pinnedpubkey开始使用该函数。 因此,这些variables都理解“ ~[username]/ ”前缀。

使剩余的两个variableshttp.sslcerthttp.sslkey也知道约定,因为它们都是文件的明确path。

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

sslCAInfo = /home/XXXX/abc.crt

运行以下命令:

 git config --global http.sslVerify false