77

I just created a github account and a repository therein, but when trying to create a local working copy using the recommende url via

git clone https://github.com/<user>/<project>.git

I get an error like

fatal: unable to access 'https://github.com/<user>/<project>.git': server certificate verification failed. CAfile: /home/<user>/.ssl/trusted.pem CRLfile: none

I'm on Debian Jessie, and I would have expected both Debian and GitHub to provide / rely on a selection of commonly accepted CAs, but apparently my system doesn't trust GibHub's certificate.

Any simple way to fix this (without the frequently recommended "GIT_SSL_NO_VERIFY=true" hack and similar work-arounds)?

EDIT:

Additional information:

  • The ca-certificate package is installed.
  • Installing cacert.org's certificates as suggested by @VonC didn't change anything.
  • My personal ~/.ssl/trusted.pem file does contain a couple of entries, but to be honest, I don't remember where the added certificates came from...

  • When removing ~/.ssl/trusted.pem, the git error message changes to

    fatal: unable to access 'https://github.com/tcrass/scans2jpg.git/': Problem with the SSL CA cert (path? access rights?)

EDIT:

@VonC's advice regarding the git https.sslCAinfo option put me on the right track -- I just added the downloaded cacert.org CAs to my trusted.pem, and now git doesn't complain anymore.

ROMANIA_engineer
  • 51,252
  • 26
  • 196
  • 186
Torsten Crass
  • 889
  • 1
  • 7
  • 6

10 Answers10

121

You can also disable SSL verification, (if the project does not require a high level of security other than login/password) by typing :

git config --global http.sslverify false

enjoy git :)

mkebri
  • 1,777
  • 1
  • 15
  • 14
  • 3
    It is not an obligation, only a (very strong) recommendation. SSL certificates are about end-to-end encryption between you and a *known* end-point. Desactivating ssl certificate exposes you to a MiM attack (https://en.wikipedia.org/wiki/Man-in-the-middle_attack) – VonC Mar 09 '17 at 12:03
  • 7
    The problem with that kind of short answer (and many others I have seen for the past 8+ years) is the complete lack of context or recommendation: One could quickly copy-paste it without understanding the consequences. – VonC Mar 09 '17 at 12:07
  • 2
    Even the CIA, in its latest WikiLeaks dump (https://en.wikipedia.org/wiki/Vault_7) tries to avoid sslVerify false: look for section "The "Workaround Self-signed Certificates" Trick" in https://wikileaks.org/ciav7p1/cms/page_1179773.html – VonC Mar 09 '17 at 12:10
  • This is true, but in another context where the same user is working with several machines (home machine, office machine ... any computer) on the same project playing with the certificate becomes binding on everything if the main objective is not to avoid an intrusion because the system is developing ...and we want to focus on that (git accept only one certificat /projet you must evry time when you change machine to generate certificate and update the setting of the project!! ) – mkebri Mar 09 '17 at 12:12
  • You can specify indeed a certif per project since Git 1.8.5: http://stackoverflow.com/a/23807432/6309 – VonC Mar 09 '17 at 12:14
  • 1
    Saved my day Dude. – Srikanth J May 15 '21 at 03:19
115

Make sure first that you have certificates installed on your Debian in /etc/ssl/certs.

If not, reinstall them:

sudo apt-get install --reinstall ca-certificates

Since that package does not include root certificates, add:

sudo mkdir /usr/local/share/ca-certificates/cacert.org
sudo wget -P /usr/local/share/ca-certificates/cacert.org http://www.cacert.org/certs/root.crt http://www.cacert.org/certs/class3.crt
sudo update-ca-certificates

Make sure your git does reference those CA:

git config --global http.sslCAinfo /etc/ssl/certs/ca-certificates.crt

Jason C mentions another potential cause (in the comments):

It was the clock. The NTP server was down, the system clock wasn't set properly, I didn't notice or think to check initially, and the incorrect time was causing verification to fail.

Certificates are time sensitive.

Community
  • 1
  • 1
VonC
  • 1,129,465
  • 480
  • 4,036
  • 4,755
  • 1
    I also get the same messages. Specifically mine says fatal: unable to access 'url/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none. I am using git over ssh. Would that make a difference? – Coded Container Aug 09 '16 at 14:09
  • @CodedContainer Yes it does: the CAs (Certificate Authorities) validate a public keys for TLS certificates (using in https). ssCAinfo has no bearing for ssh url. Are you sure your remote url does *not* start with https? – VonC Aug 09 '16 at 14:31
  • Hm. I just suddenly started getting this error today, only on one device (a Raspberry Pi) that hasn't been touched since the last time it worked. I ran through all the steps in this answer, and it grabbed some new certificates, but I'm still getting the same error (the git URL does start with https, and it's on gitlab.com). Any other ideas? – Jason C Mar 06 '17 at 01:35
  • @JasonC Is the Git version the same on those Raspberry Pi boxes? – VonC Mar 06 '17 at 05:24
  • 11
    @VonC I figured it out. It was the clock. The NTP server was down, the system clock wasn't set properly, I didn't notice or think to check initially, and the incorrect time was causing verification to fail. It was [this](http://stackoverflow.com/a/22945443/616460), after a load of other failed attempts. – Jason C Mar 06 '17 at 06:28
  • @JasonC Thank you. I have included your comment and link in the answer for more visibility. – VonC Mar 06 '17 at 07:29
  • the time was the reason in my case, nothing related with actual certificates. – logoff Dec 04 '17 at 14:21
34

I also was having this error when trying to clone a repository from Github on a Windows Subsystem from Linux console:

fatal: unable to access 'http://github.com/docker/getting-started.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

The solution from @VonC on this thread didn't work for me.

The solution from this Fabian Lee's article solved it for me:

openssl s_client -showcerts -servername github.com -connect github.com:443 </dev/null 2>/dev/null | sed -n -e '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p'  > github-com.pem
cat github-com.pem | sudo tee -a /etc/ssl/certs/ca-certificates.crt
AMS777
  • 2,761
  • 1
  • 15
  • 21
29

It can be also self-signed certificate, etc. Turning off SSL verification globally is unsafe. You can install the certificate so it will be visible for the system, but the certificate should be perfectly correct.

Or you can clone with one time configuration parameter, so the command will be:

git clone -c http.sslverify=false https://myserver/<user>/<project>.git;

GIT will remember the false value, you can check it in the <project>/.git/config file.

dmatej
  • 1,408
  • 15
  • 23
21

I had a similar problem and got the error message:

fatal: unable to access XXXX server certificate verification failed. CAfile: none CRLfile: none

It suddenly happened when I had tried to connect to my regular (WORKING!) gitlab server, SSL created with letsencrypt, from git under WSL2 ubuntu.

There were no problems accessing the server from the browser, the SSL chain seemed OK when checking with tools like https://www.sslshopper.com/ssl-checker.html

you need to update your CA certificates.

sudo apt update
sudo apt upgrade
sudo apt-get install --reinstall ca-certificates
sudo update-ca-certificates


# now it should work perfectly
git pull

it might happend because of this:
https://techcrunch.com/2021/09/21/lets-encrypt-root-expiry/

Wazime
  • 1,236
  • 15
  • 26
  • 1
    Below modification helped me resolve issue on AWS Codepipeline `sudo apt update -y sudo apt upgrade -y sudo apt-get install --reinstall ca-certificates sudo update-ca-certificates --fresh -v` – chen Oct 05 '21 at 08:12
  • All I seemed to need was `sudo apt update` and `sudo apt-get install --reinstall ca-certificates` thanks! (ubuntu 18.04 wsl) – rogerdpack Oct 16 '21 at 04:32
6

Another possible cause is that the clock of your machine is not synced (e.g. on Raspberry Pi). Check the current date/time using:

$ date

If the date and/or time is incorrect, try to update using:

$ sudo ntpdate -u time.nist.gov

Or, on a virtual machine (e.g. Ubuntu VirtualBox):

$ timedatectl set-ntp no
$ timedatectl set-time YYYY-MM-DD
$ timedatectl set-time HH:MM:SS
$ timedatectl set-ntp yes
khaverim
  • 3,078
  • 5
  • 33
  • 46
Nguyễn Minh Vũ
  • 343
  • 3
  • 6
1

To me a simple

sudo apt-get update

solved the issue. It was a clock issue and with this command it resets to the current date/time and everything worked

rakwaht
  • 3,220
  • 1
  • 25
  • 42
0

What worked for me when getting such an error (happened with gitlab for me):

fatal: unable to access 'https://github.com/<user>/<project>.git': server certificate verification failed. CAfile: /home/<user>/.ssl/trusted.pem CRLfile: none

was to get the .pem file from the certificate page of the website (accessible when clicking on the lock icon left of the url) and directly copy it into the folder /etc/ssl/certs/. From there, git was able again to interact with gitlab.

LoW
  • 470
  • 4
  • 11
0

For me, simply removing sudo solved.

I was trying to sudo git clone ..., just doing a git clone worked.

ymudyruc
  • 57
  • 8
-2

Try to connect to repositroy with url: http://github.com/<user>/<project>.git (http except https)

In your case you should clone like this: 

git clone http://github.com/<user>/<project>.git
Егор Поляков
  • 72
  • 1
  • 2