14

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://slimsnerdy@github.com':
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.

Snerd
  • 1,463
  • 3
  • 25
  • 36

3 Answers3

11

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.

Adrian W
  • 4,563
  • 11
  • 38
  • 52
  • 2
    Agree - it's definitely not an SSL issue. I _suspect_ (without much evidence) that the proxy is stripping Basic credentials for some stupid reason. If that's true, it's going to be _very_ challenging to make this work correctly over HTTP(S). – Edward Thomson May 31 '18 at 13:49
  • This is EXACTLY it. The authentication details when asked (username/pass) are being stripped completely and this results in the "anonymous" error. – Snerd May 31 '18 at 14:13
  • Any way Fiddler can come to the rescue? – Snerd May 31 '18 at 14:16
  • 1
    Fiddler is a debugging proxy which sits between your client and the internet. Thus you would only see the communication between the client and your company's proxy. What you would need is a trace of the communication beween your company's proxy and the internet. – Adrian W May 31 '18 at 17:32
  • If you have a web server under your control (and outside your company), you could test the behavior of your company's proxy against your own server. – Adrian W May 31 '18 at 17:35
  • @AdrianW My logic was using Fiddler to send to the proxy (company) what it wants to authenticate.. as in replace the SSL before it hits the proxy with what is "desired" by the proxy. – Snerd Jun 01 '18 at 23:05
  • @Snerd when the proxy denies the connection, you get `fatal: unable to access '....' The requested URL returned error: 403`. The message you get is `remote: Anonymous access .... denied`. This message is from the remote git, i.e. GitHub. – Adrian W Jun 02 '18 at 20:10
  • 1
    Do you need help on how to route git through fiddler? – Adrian W Jun 02 '18 at 20:12
  • 2
    @Edward Thomson one part of the evidence is the message from `remote` saying `Anonymous access denied`. A trace of the original request with Fiddler, as suggested by OP, would very likely show `Authorization Header is present` and thus complete the evidence. – Adrian W Jun 02 '18 at 21:38
  • @AdrianW yes help with routing Git through Fiddler would help. – Snerd Jun 05 '18 at 03:36
  • @Snerd I updated the answer to include an example on how to route git's web I/O through Fiddler. Fiddler uses its own man-in-the-middle certificate. To allow git to accept it, I chose to add `-c http.sslVerify=false` on the command line. So, it will be accepted for this request only and it is not necessary to change the configuration permanently. – Adrian W Jun 05 '18 at 19:25
  • 1
    @Snerd FYI: Updating git for windows (to 2.17.x) offers an option to chose an HTTPS transport backend. Choices: _Use the OpenSSL library_ and _Use the native Windows Secure Channel library_. Description for the latter: _Server certificates will be validated using Windows Certificate Stores. This option also allows you to use your company's internal Root CA certificates distributed e.g. via Active Directory Domain Services._ I.e. no longer necessary to tweak ca-bundle.crt. – Adrian W Jun 07 '18 at 11:16
  • @AdrianW I tried using the Windows library during another reinstall.. it didn't work, unless I missed something? But it DOES make sense. – Snerd Jun 07 '18 at 18:54
  • Just a finding I wanted to share. – Adrian W Jun 07 '18 at 18:57
4

I am sure this could help you.

git config --global http.sslVerify false

As you may guess, this command changes ssl setting to disable ssl verification.

Warning: This method is insecure.

If you want it back, you can enable anytime.

git config --unset http.sslVerify

Miron
  • 1,007
  • 2
  • 17
  • 31
4

For testing disable temporally SSL for your repository with:

git config http.sslVerify false

Then also check that your system clock is in sync since this can influence how SSL verification works, you may get something like:

[SSL certificate problem, verify that the CA cert is OK. 
Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed])

Try to use ntp/chrony to synchronize your system clock.

Then to get the certificate you could use:

openssl s_client -showcerts -connect github.com:443 < /dev/null

Get everything within -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- and create a cert.pem

Then use that file as you are trying in http.sslCAInfo:

git config http.sslCAInfo /path/to/cert.pem

Once done try enabling back the http.sslVerify:

git config --unset http.sslVerify
nbari
  • 25,603
  • 10
  • 76
  • 131