Server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

TLDR:

hostname=XXX
port=443
trust_cert_file_location=`curl-config --ca`

sudo bash -c "echo -n | openssl s_client -showcerts -connect $hostname:$port -servername $hostname \
    2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  \
    >> $trust_cert_file_location"

Warning: as noted in gareththered's excellent answer, this adds all certificates, instead of only the Root CAs.
Blindly adding all (any) certificate to your trustStore without due diligence is not the best course of action.

Long answer

The basic reason is that your computer doesn't trust the certificate authority that signed the certificate used on the Gitlab server. This doesn't mean the certificate is suspicious, but it could be self-signed or signed by an institution/company that isn't in the list of your OS's list of CAs. What you have to do to circumvent the problem on your computer is telling it to trust that certificate - if you don't have any reason to be suspicious about it.

You need to check the web certificate used for your gitLab server, and add it to your </git_installation_folder>/bin/curl-ca-bundle.crt.

To check if at least the clone works without checking said certificate, you can set:

export GIT_SSL_NO_VERIFY=1
#or
git config --global http.sslverify false

But that would be for testing only, as illustrated in "SSL works with browser, wget, and curl, but fails with git", or in this blog post.

Check your GitLab settings, a in issue 4272.

To get that certificate (that you would need to add to your curl-ca-bundle.crt file), type a:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGitlabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

(with 'yourserver.com' being your GitLab server name, and YourHttpsGitlabPort is the https port, usually 443)

To check the CA (Certificate Authority issuer), type a:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGilabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  | openssl x509 -noout -text | grep "CA Issuers" | head -1

Note: Valeriy Katkov suggests in the comments to add -servername option to the openssl command, otherwise the command isn't showed certificate for www.github.com in Valeriy's case.

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

Findekano adds in the comments:

to identify the location of curl-ca-bundle.crt, you could use the command

curl-config --ca

Also, see my more recent answer "github: server certificate verification failed": you might have to renistall those certificates:

sudo apt-get install --reinstall ca-certificates
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
git config --global http.sslCAinfo /etc/ssl/certs/ca-certificates.crt

---

Note: This has major security implications.

Open your terminal and run following command:

export GIT_SSL_NO_VERIFY=1

It works for me and I am using Linux system.

---

Another cause of this problem might be that your clock might be off. Certificates are time sensitive.

To check the current system time:

date -R

You might consider installing NTP to automatically sync the system time with trusted internet timeservers from the global NTP pool. For example, to install on Debian/Ubuntu:

apt-get install ntp

---

Note: This has major security implications.

If you are using a git server inside a private network and are using a self-signed certificate or a certificate over an IP address ; you may also simply use the git global config to disable the ssl checks:

git config --global http.sslverify "false"

---

Had same problem. Caused by self issued certificate authority. Solved it by adding .pem file to /usr/local/share/ca-certificates/ and calling

sudo update-ca-certificates

PS: pem file in folder ./share/ca-certificates MUST have extension .crt

---

Check your system clock,

$ date

If it's not correct the certificate check will fail. To correct the system clock,

$ apt-get install ntp

The clock should synchronise itself.

Finally enter the clone command again.

---

Lets's encrypt Sept. 30th 2021 ROOT CA expiry

Another source for this error is an expired Root CA, it happened yesterday for one of them if you're using Let's Encrypt: https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/

You can confirm it by running

openssl s_client -showcerts -connect $hostname:$port -servername $hostname | grep "certificate has expired"

In this case you need to edit the gitlab certificate, in /etc/gitlab/ssl/$hostname.crt

Replace expired DST Root CA X3 block in file with content of https://letsencrypt.org/certs/isrgrootx1.pem, and reload the server.

---

GIT_CURL_VERBOSE=1 git [clone|fetch]…

should tell you where the problem is. In my case it was due to cURL not supporting PEM certificates when built against NSS, due to that support not being mainline in NSS (#726116 #804215 #402712 and more).

---

Last updated: Sep 30, 2021 | See all Documentation

The main determining factor for whether a platform can validate Let’s Encrypt certificates is whether that platform trusts ISRG’s “ISRG Root X1” certificate. Prior to September 2021, some platforms could validate our certificates even though they don’t include ISRG Root X1, because they trusted IdenTrust’s “DST Root CA X3” certificate. From October 2021 onwards, only those platforms that trust ISRG Root X1 will validate Let’s Encrypt certificates (with the exception of Android).

Current system

In case your system is quite current but for some reason automatic update didn't work, there should be enough to:

apt update
apt upgrade
sudo dpkg-reconfigure ca-certificates

and in reconfigure stage, deselect "DST Root CA X3" certificate

Outdated system

To resolve, on old Linux server like Ubuntu 16 or Debian 8 jessie, few steps required:

upgrade openssl to anything >=1.0.2 On Debian jessie enable backports source, add this line to sources.list: deb http://archive.debian.org/debian jessie-backports main contrib non-free and do apt-get install -t jessie-backports openssl

ensure security updates for ca-certificates package apt upgrade

download latest LetsEncrypt root CA certs: sudo curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt -o /usr/local/share/ca-certificates/isrgrootx1.crt sudo curl -k https://letsencrypt.org/certs/letsencryptauthorityx1.pem.txt -o /usr/local/share/ca-certificates/letsencryptauthorityx1.crt sudo curl -k https://letsencrypt.org/certs/letsencryptauthorityx2.pem.txt -o /usr/local/share/ca-certificates/letsencryptauthorityx2.crt sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx1.crt sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx2.crt sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx3.crt sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x4-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx4.crt sudo dpkg-reconfigure ca-certificates

during reconfigure stage, please deselect "DST Root CA X3" certificate

After these steps, apt update should work for LetsEncrypt based sources and wget and curl should not complain.

Special note to curl -k allows to connect 'insecure' SSL server, which is the case, as LetsEncrypt certificate is not trusted.

---

Or simply run this comment to add the server Certificate to your database:

echo $(echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpGilabPort 2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p') >> /etc/ssl/certs/ca-certificates.crt

Then do git clone again.

---

The most voted for answer is, unfortunately, wrong. It will have the desired effect, but for the wrong reasons.

The commands in VonC's answer adds all certificates in the chain to the trust-anchor store. However, these certificates are not trust-anchors (or Root CA certificates in other words); they are the end-entity and intermediate CA certificates.

The standard for TLS RFC 5246 states:

certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

Therefore VonC's (and others') command may well add all the wrong certificates and not the Root CA.

A end-entity or intermediate CA certificate is not a trust-anchor. These certificate may and do change over time, in which case the same problem will rear it's ugly head again. Also, what happens if the end-entity certificate is revoked for some reason? Your computer may well continue to trust the revoked certificate - in practice, the exact response may depends on the crypto library being used as this isn't well defined in the standards and therefore subject to variation in implementation.

The correct way to fix this would involve looking at the last certificate in the chain, confirming it is not a Root CA (as that may be sent by the server - see the RFC extract quoted above) and if that is the case, looking at the Issuer and potentially the AKI field to ascertain which Root CA issued this first intermediate CA certificate. Once the details have been worked out, you'll need to visit the repository of that Root CA and download (and verify the hash) of that certificate before downloading it. You should review the CP/CPS of this Root CA before deciding to install it in your trust-anchor store.

If the last certificate is the Root CA, then use openssl x509... commands to view the details, then carry out due-diligence before deciding whether you should install that single certificate in your trust-anchor store.

There can't be, and shouldn't be, an automatic process for you to carry out the above as you need to verify the provenance of the trust-anchor before you decide to add it to your trust-anchor store. Ask yourself why it wasn't part of the ca-certificate package (or equivalent for your distro) before blindly installing it.

However, running something like the following will display the Subject and Issuer of the last certificate in the chain, which may help you trace down the missing Root CA certificate:

echo -n | openssl s_client -showcerts -servername www.github.com -connect www.github.com:443 2>/dev/null | tac | awk '/-END CERTIFICATE-/{f=1} f;/-BEGIN CERTIFICATE-/{exit}' | tac | openssl x509 -noout -subject -issuer

Which (in my case in late May 2021) results in:

subject=C = US, O = "DigiCert, Inc.", CN = DigiCert High Assurance TLS Hybrid ECC SHA256 2020 CA1
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA

From the above, we can see that the server sent the intermediate CA certificate, not the root (the subject and issuer are different). That intermediate CA certificate was signed by DigiCert's High Assurance EV Root CA. We can now go to DigiCert's repository and download that particular certificate.

Before installing that certificate, make sure it is the one which signed your intermediate CA by running openssl x509 -noout -text -in <downloaded.crt.pem> against it and comparing the value of the X509v3 Authority Key Identifier extension against the same extension in the certificate sent by the server. Note: you can view that extension on the intermediate CA certificate sent by the server by changing -subject -issuer at the end of the previous command to -text.

Once you're certain that the Root CA certificate you've downloaded is the correct one, and you've carried out due-diligence and decided that you trust this Root CA, add it to your trust-anchor store:

sudo mv <downloaded.crt.pem> /usr/local/share/ca-certificates/<downloaded.crt>
sudo update-ca-certificates

Note that the file must be in PEM format and the filename must end in .crt otherwise update-ca-certificates won't recognise it.

---

What i did to solve this problem in the terminal(Ubuntu 18.04):

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

I got two chunks of certificate chunks. And i copied the certificate chunks to my certificate file to /etc/ssl/certs/ca-certificates.crt.

---

I messed up with my CA files while I setup up goagent proxy. Can't pull data from github, and get the same warning:

server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

use Vonc's method, get the certificate from github, and put it into /etc/ssl/certs/ca-certificates.crt, problem solved.

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

---

I tried many solutions from here but none worked for me. I had 4 servers running on ubuntu 16.04, and the way I was actually able to fix this problem was 3-fold (you should sudo apt update first):

update openssl as the version I had installed was missing a fix that would allow some of the solutions here to work. sudo apt install --only-upgrade openssl. Openssl needs to be at least 1.0.2g-1ubuntu4.20.

then I had to do the same with the certs: sudo apt install --only-upgrade ca-certificates

only then did reconfiguring the certs sudo dpkg-reconfigure ca-certificates (or editing the config file I guess) and removing the DST_Root_CA_X3 from the list bring positive results.

---

there is no need to set git ssl verification to set to false. It is caused when the system does not have the all CA authority certificates. Mostly people who have genuine SSL certificate missing the intermediate certificate.

Just adding the complete text of intermediate certificate (whole chain of missing CA and intermediate certificate) to

sudo gedit /etc/ssl/certs/ca-certificates.crt 

works without running the update-ca-certificates.

Same goes for manually generated certificates, just add the CA certificate text.

At the end : Push successful: Everything is up-to-date

---

For Linux/Debian use:

sudo cp /etc/ca-certificates.conf /etc/ca-certificates.conf.orig
sudo nano /etc/ca-certificates.conf
Change “mozilla/DST_Root_CA_X3.crt” in “!mozilla/DST_Root_CA_X3.crt” an save
sudo update-ca-certificates

https://talk.plesk.com/threads/lets-encrypt-root-certificate-expiration-on-30-september-2021.362224/

---

I met this issue in a GitLab server. Solved it after updating the Trusted CA List of Linux by the cmd:

sudo apt-get install --reinstall ca-certificates

Here are the steps:

The git trace return errors like this:

 GIT_CURL_VERBOSE=1 GIT_TRACE=2 git clone https://mygitlab
...
...

* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile: none CRLfile: none
* Closing connection 0
**fatal: unable to access 'https://mygitlab/some.git/': server certificate verification failed. CAfile: none CRLfile: none**

Check the CA Issuer of git server:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpGilabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  | openssl x509 -noout -text | grep"CA Issuers" | head -1
...
...

CA Issuers - URI:http://r3.i.lencr.org/

Why is the r3.i.lencr.org untrusted? I tried to update the CA list, and it works.

---

sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates -y 
sudo update-ca-certificates

works for me.

---

What worked for me when trying to git clone inside of a Dockerfile was to fetch the SSL certificate and add it to the local certificate list:

openssl s_client -showcerts -servername git.mycompany.com -connect git.mycompany.com:443 </dev/null 2>/dev/null | sed -n -e '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p'  > git-mycompany-com.pem

cat git-mycompany-com.pem | sudo tee -a /etc/ssl/certs/ca-certificates.crt

Credits: https://fabianlee.org/2019/01/28/git-client-error-server-certificate-verification-failed/

---

I faced the problem with my Jenkins. When I have renewed the certificate I started facing this error.

stderr fatal: unable to access server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt

So I have added my new certificate in the following file:

/etc/ssl/certs/ca-certificates.crt

The content of that file looks like this:

-----BEGIN CERTIFICATE-----
blahblha
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
blahblha
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
blahblha
-----END CERTIFICATE-----

Just append your certificate in the bottom:

-----BEGIN CERTIFICATE-----
blahblha
-----END CERTIFICATE-----

---

I installed Xubuntu on a Raspberry pi 2, found the same issue with time, as NTP and Automatic Server sync was off (or not installed) . Get NTP

sudo apt-get install ntp

and change the "Time and Date" from "Manual" to "Keep synchronized with Internet Servers"

---

The first thing you should check for is the file permission of /etc/ssl and /etc/ssl/certs.

I made the mistake of dropping file permissions (or blowing away the SSL rm -rf /etc/ssl/* directories) when using ssl-cert group name/ID while working on my Certificate Authority Management Tool.

It was then that I noticed the exact same error message for wget and curl CLI browser tools:

server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Once I brought the /etc/ssl and /etc/ssl/cert directories' file permission up to o+rx-w, those CLI browser tools started to breath a bit easier:

mkdir -p /etc/ssl/certs
chmod u+rwx,go+rx /etc/ssl /etc/ssl/certs

I also had to recreate Java subdirectory and reconstruct the Trusted CA certificate directories:

mkdir /etc/ssl/certs/java
chmod u+rwx,go+rx /etc/ssl/certs/java
update-ca-certificates

and the coast was clear.

---

I was facing the same problem with aging Ubuntu 16.04 and GitLab (other computers worked well).

The problem was actually the old version of gnutls library which is used internally by Git. This old library was sensitive for the certificate order on the server side - more information in this question. The final solution was as simple as:

apt-get update
apt-get upgrade libgnutls*

---

I just encountered the very same problem with a git repository which always works for me. The problem was that I accessed it through public WiFi access, which redirects to a captive portal upon the first connection (for example to show ads and agree with tos).

---

Eventually, add the http.sslverify to your .git/config.

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = https://server/user/project.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[http]
        sslVerify = false

---

For MINGW64 Git Bash users on Windows

Launch Git Bash as Administrator

From within the MINGW64 terminal run: echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGitlabPort 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' >> /c/Program\ Files/Git/mingw64/ssl/certs/ca-bundle.trust.crt

Close Git Bash as Administrator

Launch Git Bash (as not Administrator)

From within the MINGW64 terminal run: $ git config --global http.sslBackend schannel $ git config --global http.sslverify true

---

Based on the very good answer from VonC, I just created a bash script that installs the missing x509 certificate to your certificate bundle. It's for debian based linux distros.

#!/bin/bash

CERTIFICATE_PEM=certificate.pem
CERTIFICATE_CRT=certificate.crt

# get certificate
echo -n | openssl s_client -showcerts -connect gitlab.sehlat.io:443 \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  > $CERTIFICATE_PEM

# format certificate from PEM (human-readable) to CRT
openssl x509 -in $CERTIFICATE_PEM -out $CERTIFICATE_CRT

# move it to ca-certificates folder & update the bundle file
sudo mv ./$CERTIFICATE_CRT /usr/local/share/ca-certificates/
sudo update-ca-certificates

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

---

Have the certificate and bundle copied in one .crt file and make sure that there is a blank line between the certificates in the file.

This worked for me on a GitLab server after trying everything on the Internet.

---

Before anything else, check if you have a proxy running, like Zscaler, that you can temporarily turn off. Then check your dates, as above.

---

I ran into this problem today with freedesktop.org, when using Git for Windows. I updated my git version to 2.35 (from 2.28), and the problem was solved. Probably the integrated shell environment in the windows version did not have updated certs.

Hopefully this helps someone who uses the Windows version.

---