git clone works but push doesn't after replacing SSL certificate behind firewall

Question

Cloning my repo works; pushing back to it doesn't.

1st cloning did not work:

git clone https://github.com/slimsnerdy/testy.git
Cloning into 'testy'...
fatal: unable to access 'https://github.com/slimsnerdy/testy.git/': SSL certificate problem: self signed certificate in
certificate chain

So I added to the .gitconfig file the following custom certificate:

[http]
    sslCAInfo = U:/ca-bundle.crt

Now cloning works:

Cloning into 'testy'...
remote: Counting objects: 25, done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 25 (delta 8), reused 6 (delta 1), pack-reused 0
Unpacking objects: 100% (25/25), done.

Ok now pushing:

new-item test.txt
git add *
git commit -m "push test"
git push
Username for 'https://github.com': slimsnerdy
Password for 'https://[email protected]':
remote: Anonymous access to slimsnerdy/testy.git denied.
fatal: Authentication failed for 'https://github.com/slimsnerdy/testy.git/'

When I try to push via a personal hotpot using my phone (circumventing the corporate firewall), it pushes fine.

Why is clone working with the custom certificate but not push? I want to get around this without using ssh.

Answer 1

Your company's firewall has installed a proxy which acts as man in the middle. To that end, it creates certificates for the sites you visit, e.g. github.com. These certificates obviously have a different issuer (your company's internal CA) which will not be trusted by the git client by default. Turning off sslVerify forces the git client to accept any certificate from any issuer. This is potentially dangerous. Your original approach, to add your company's CA to the list of issuers trusted by the git client, is IMHO the better way to allow your git client to talk to github.com from behind your company's firewall.

So why doesn't this setup let you push? What the other posters overlooked so far, is that the error in this case is not an SSL error. Only your client sees your company's certificate. If that is solved, it is solved. Github does not see this certificate. So any further tweaking with SSL settings will not help.

I could reproduce your case in so far as I could first see the SSL self-signed certificate problem which disappeared when I added the proxy's certificate to sslCAInfo. The bad news: I could not reproduce the authentication failed error. A push to github just worked. The good news: pushing to github from a setup similar to your's is possible.

If it is not a SSL problem, then it can only be caused by the proxy. Because the proxy presents its own certificate to the client, it is able to decrypt the SSL traffic and do a deep inspection of the data exchanged. The proxy does have the power to disable certain commands, to restrict access to specific sites or to strip username/password from requests.

Please talk to the IT security folks in your company. They should be able clarify whether the proxy imposes access restrictions for github or for certain git commands.

Update

Routing git web traffic through Fiddler can be acomplished as follows (use git from the command line):

1. Run Fiddler
2. In git bash, cd to your working directory and add the options -c http.sslVerify=false -c http.proxy=127.0.0.1:8888 to the git command.

Example:

$ git -c http.sslVerify=false -c http.proxy=127.0.0.1:8888 push

In Fiddler, you should now see something like:

2   200 HTTP    Tunnel to   github.com:443  0           git-remote-https:6512           
3   401 HTTPS   github.com  /xxx/xxxx.git/info/refs?service=git-receive-pack [...]      
4   200 HTTPS   github.com  /xxx/xxxx.git/info/refs?service=git-receive-pack [...]          

Or, exported with "terse summary" (Ctrl/Shift/T):

CONNECT http://github.com:443
200 Connection Established ()

GET https://github.com/xxx/xxxx.git/info/refs?service=git-receive-pack
401 Authorization Required (text/plain)

GET https://github.com/xxx/xxxx.git/info/refs?service=git-receive-pack
200 OK (application/x-git-receive-pack-advertisement)

In the right pane of the Fiddler Web Debugger, you can further investigate the data exchanged. Especially for the last of the three request shown above, you should see something like this in the "Headers" tab:

GET /xxx/xxxx/info/refs?service=git-receive-pack HTTP/1.1
Host: github.com
Authorization: Basic XyzzY1337qQ=
User-Agent: git/2.13.0.windows.1
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache

Thus you can prove that your client indeed sent authorization info. If not, I would be very interested in the results.