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.
3 Answers
Answers 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.
Answers 2
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.
Answers 3
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 
0 comments:
Post a Comment