git and HTTPS (fatal: HTTP request failed)
Friday, January 10. 2014
Two facts first about git:
- A number of sites tells you to use git:// or ssh:// instead of https://. Apparently there is some unnecessary complexity when piggy-backing over HTTP-secure.
- I personally don't like git due to it's complexity. Its like a requirement of being an experienced mechanic before getting a driver's license. You can drive a car without exact technical knowledge about the inner workings of a car. But that seems to be the only way to go with git.
So, I choose to run my own repo on my own box and do it over HTTPS. Since HTTPS is a 2nd class protocol in the git-world many simple things are unnecessarily difficult.
My initial attempt was to do a simple clone from my existing repo:
git clone https://me@my.server/my/Project
Well, that doesn't end well. There is this fully explanatory fatal: HTTP request failed -error. Adding --verbose does not help. Then I found a fact that git uses curl as it's HTTPS-transport client and very helpful environment variable to diagnose the problem:
export GIT_CURL_VERBOSE=1
git clone https://me@my.server/my/Project
That way I got the required debug-information about Certificate Authority -certificates being used. It didn't use my own CA's file at all.
The next fix was to tweak the configuration:
git config --global http.sslverify false
It made my clone working! That, however, is not the way I do computer security. I need my certificates verified. From git-config(1) man-page I found the required piece of information. Adding the CA-root path of my Linux-distro makes the entire thing working:
git config --global http.sslverify true
git config --global http.sslCAPath /etc/pki/tls/certs
Finally I found the good site about all this: http://stackoverflow.com/questions/3777075/ssl-certificate-rejected-trying-to-access-github-over-https-behind-firewall/4454754 It seems to contain all this information.
Unfortunately too late! But wouldn't it be great for git to emit the proper error message about the "Peer's certificate issuer is not recognized"? That was the original problem to begin with. Also, why don't CentOS-people configure their curl-library to behave like OpenSSL does?
