99

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
  • 54,432
  • 29
  • 203
  • 199
Torsten Crass
  • 1,109
  • 1
  • 8
  • 6

13 Answers13

145

2016: 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.

2022: Auspex adds in the comments:

ca-certificates does indeed contain root certificates.
It doesn't contain the CAcert root certificates.

This might have been a good answer 6 1/2 years ago, but those certificates were suspect way back then and haven't improved.
There's a reason they're not in the ca-certificates package.

These days we have LetsEncrypt, so everyone has certificates with reliable auditing and nobody needs to rely on CAcert.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 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
  • `ca-certificates` does indeed contain root certificates. It doesn't contain the CAcert root certificates. This might have been a good answer 6 1/2 years ago, but those certificates were suspect way back then and haven't improved. There's a reason they're not in the `ca-certificates` package. These days we have LetsEncrypt, so everyone has certificates with reliable auditing and nobody needs to rely on CAcert – Auspex Aug 26 '22 at 11:25
  • 1
    @Auspex Good point, thank you for the feedback. I have included your comment in the answer for more visibility. – VonC Aug 26 '22 at 11:38
139

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
  • 2,025
  • 1
  • 16
  • 14
  • 5
    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
  • 16
    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
52

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
  • 4,609
  • 1
  • 18
  • 21
  • 6
    Same! VonC's answer doesn't work me, probably because I'm in WSL too. This answer solved the problem. – asa Jan 17 '21 at 10:43
  • 2
    I struggled for two days and this finally resolved the issue for me :) – Neeraj Gulia Jul 30 '21 at 19:26
  • This works for me, on a self-hosted gitlab instance where I changed all `github.com` to my domain, but won't it stop working when the LetsEncrypt certificate expires in two months (maybe sooner, when I replace the cert in a month)? – Auspex Aug 26 '22 at 11:44
  • In hindsight, I think I'm wrong in the comment above. When you add the certificates this way it's adding all of the leaf, root, and intermediate certificates individually, and while the leaf will expire in a couple of months, the root certificate is what was needed. Though even that has an expiry. But the root certificate for _this_ site expires in 2035. – Auspex Sep 07 '22 at 10:23
33

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,518
  • 15
  • 24
25

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,423
  • 1
  • 18
  • 26
  • 2
    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` – chendu Oct 05 '21 at 08:12
  • 3
    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
  • this works if you have updates or extended support - but if you are outside of that window, there are no updates. – cgseller Apr 21 '23 at 16:05
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,386
  • 5
  • 36
  • 46
Nguyễn Minh Vũ
  • 380
  • 3
  • 7
3

In Linux terminal, run following command:

export GIT_SSL_NO_VERIFY=1

It works for me. So Simple!!

Note: This has major security implications.

shgnInc
  • 2,054
  • 1
  • 23
  • 34
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,666
  • 3
  • 28
  • 45
  • `apt-get update` won't fix an incorrect clock. I suspect that what happened is that your clock was wrong enough that ntpdate (or whatever you're using to get the time) was fixing it by _slewing_ -- that is making very small changes to the clock until it's correct rather than changing in a single jump -- and that `apt update` took long enough that your clock was right when it finished. – Auspex Aug 26 '22 at 12:30
1

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
  • 582
  • 7
  • 15
1

For me, simply removing sudo solved.

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

ymudyruc
  • 77
  • 9
0

This is an edge case, but I think worth mentioning.

In my case, I had an Apache server proxying for a GitLab instance. GitLab is supposed to handle LetsEncrypt certificates internally, but it's become broken on my server, and I can't figure out how to fix it. Consequently, the Apache server receives HTTPS requests and is configured with a valid certificate, and forwards the requests over HTTP to the GitLab server. Browsing the GitLab site worked perfectly, showing a valid certificate.

The GitLab server, however, by default promotes any HTTP request to HTTPS whenever external_url uses the HTTPS protocol. And there was still a broken LetsEncrypt certificate on the internal NGINX server. While this seemed to make no difference at all within browsers, it made any operations using the git CLI fail!

Setting nginx['redirect_http_to_https'] = false in the gitlab.rb configuration makes the communication from proxy to GitLab server work purely over HTTP, with the proxy handling HTTPS communication with the client.

Auspex
  • 2,175
  • 15
  • 35
0

If you don't have sudo rights, you can still add the remote server's certificate to your local Git configuration without updating the system's certificate store. Here's the process:

  1. Download the server's certificate and add it to your local Git configuration as a trusted certificate. Follow these steps:

  • Download the certificate from the remote server:

    echo -n | openssl s_client -showcerts -connect gitlab_url:443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ssl_certificate.crt

  • Add the certificate to your Git configuration:

    git config --local http.sslCAInfo /path/to/ssl_certificate.crt

/!\ If the command doesn't output anything, it's possible that the server is not serving a certificate, or there might be an issue with your OpenSSL installation.

As an alternative, you can try to download the certificate using a browser:

  1. Visit the URL https://your_gitlab.url in your browser.

  2. Click on the padlock or "Secure" icon next to the URL in the address bar. View the certificate details. The exact steps to view the certificate details vary between browsers.

For example:

  • In Chrome, click on "Certificate (Valid)" in the connection tab, then click on the "Details" tab.

  • In Firefox, click on "More Information," then "View Certificate." Export the certificate as a file (usually in the X.509 Certificate format with .crt). Save the certificate to your local machine.

  1. Once you have the certificate file, you can add it to your Git configuration:

    git config --local http.sslCAInfo /path/to/ssl_certificate.crt

Nour SIDAOUI
  • 164
  • 5
-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
Егор Поляков
  • 92
  • 1
  • 2