Github: 服务器证书验证失败

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.

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 :)

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.

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

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

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

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

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/

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.

For me, simply removing sudo solved.

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

In Linux terminal, run following command:

export GIT_SSL_NO_VERIFY=1

It works for me. So Simple!!

Note: This has major security implications.

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.