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

Question

I can push by clone project using ssh, but it doesn't work when I clone project with https.

The error message that it shows me is:

server certificate verification failed. CAfile: /etc/ssl/certs/cacertificates.crt CRLfile: none

Eructate

For those having the error since yesterday it's a Let's Encrypt root CA that has expired, check my answer here https://mcmap.net/q/73177/-server-certificate-verification-failed-cafile-etc-ssl-certs-ca-certificates-crt-crlfile-none – Beadle

@Beadle thank you!! that is six billionty very frustrating hours i don't need to spend searching for why this suddenly happens XP – Zabrze

For anybody having this issue just recently 5 days ago the node:15 docker image started having this error, upgrading to node:16 solved it for me – Fairspoken

if you are here because your git server uses the new Let's Encrypt certificate (after the old one expired September 30th, 2021) that your Ubuntu system might not know yet (which causes this kind of error message in git), do: sudo apt update ; sudo apt-get install apt-transport-https ca-certificates -y ; sudo update-ca-certificates to update the certificates installed on your system. – Dollarfish

On my machine, that error was due to an outdated version of libgnutls, which was used by git for cloning (maybe libgnutls was embedding certs, and didn't use ca-certificates, which caused it to not trust the Let's Encrypt certificate, but I'm not sure). I solved it by running sudo apt update; sudo apt install -y libgnutls30 – Wolverine

Just one quick answer: Check your system date. On one of my old machines, the system date is 5 months behind and I saw exactly the same error for git and apt. And apt update says Release file for xxx is not valid yet (invalid for another 156d 21h 56min 26s). After I synchronized the time, everything back to normal. – Shrunk

Read this article, which provides a step-by-step guide on installing an SSL certificate, hope this article is helpful: noorui.com/blog/… – Bigley

Answer 1

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

Shorts

Doesn't the original message indicate where to add the certificate to? In my case curl-config --ca returned /etc/ssl/certs/ca-certificates.crt, which is where I had to add the certificate. Apart from that this answer was the first information pointing me in the right direction with this issue – Tica

How do you find the git install folder? – Stoker

@Stoker it depends on your OS. On Linux, you can do a which git. – Shorts

I don't even have curl-config available on Debian Wheezy (7.11) but the error message seems to point to where to put it – Biauriculate

Moreover the command to get the certificate does not produce any result (hangs). Disabling certificate verification works (even if insecure) – Biauriculate

Do you know why a trusted Comodo cert (browsers trust it without issue) would cause this? git doesn't like it on Mac OS and Ubuntu 16 but browsers trust it – Unthoughtof

@Unthoughtof Maybe because that certificate was not installed (askubuntu.com/a/859887/5470), but was present in the browser internal certificate store? – Shorts

Interestingly, this worked for a corporate server before, but then failed again... in googling around, I found this post, which suggests importing the top level cert, which did work. Is there a way to make this follow the chain from child up to the root cert? – Asthenopia

@Asthenopia Not sure, but yes, intermediate and root CA needs to be there in the crt file. – Shorts

@Shorts Thanks. I ended up downloading each cert in the trust hierarchy by clicking the lock symbol from Firefox, then View Certificate, then Details. I saved them one by one, which is basically the same as what your sed bit does. I will add, I ended up moving these to my distro's ca-certificate folder as I believe your method will be overwritten when the ca-certificates package updates! – Asthenopia

Downvoted, as this is simply wrong. It will have the desired effect, but for the wrong reasons. This 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 subscriber and intermediate CA certificates. – Assize

@Assize good point. How to add only root CA, in the context of this question? – Shorts

@Shorts - please see below. Let me know your thoughts :-) – Assize

How "to check the web certificate used for your gitLab server" ? – Teach

@EkaterinaIvanovaiceja.net I mention how to get that certificate (openssl s_client -showcerts -connect) in the answer. But you meed to confirm with the remote hosting service if that certificate is indeed theirs (or if you just got one from a MIM -- man In the Middle -- attack). Query it from different network to make sure you get the same certificate. – Shorts

That resolve my probleme : git config --global http.sslverify false – Terranceterrane

@Terranceterrane It does indeed, for testing. But disabling SSL verification is considered as a bad practice, and should be avoided if possible. – Shorts

Answer 2

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.

Swint

Not downvoting because it's a workaround for when you know what you are doing. However, strongly recommend against this in the general case. – Mellifluent

I wouldn't say its a workaround when you know what you're doing. When you know what you're doing you should look at a certificate failing as "maybe someone hacked us" not "oh well security says someone hacked us, guess we need to disable security." It's at best a stopgap measure if something needs to get pushed asap. – Morula

by exporting above flag i get below error.error: RPC failed; result=22, HTTP code = 403 fatal: The remote end hung up unexpectedly error: RPC failed; result=22, HTTP code = 403 fatal: The remote end hung up unexpectedly – Albur

Only worked for me with git config --global http.sslverify false – Palliate

If I do that, then I ma asked for the password and none user/ pass I use with GitLab to push pull code doesn't work? – Dituri

Note: you can disable verification for one repo only (instead of globally for all repos) by running git config http.sslVerify false in your local repo. – Nascent

This is a good workaround when you have a proxy configuration, this is normal the case on an enterprise network. Better than the "git config http.sslVerify false" as is it not persistent. – Insole

Answer 3

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

Weeks

This was my problem. My university was blocking ntp packets, which was preventing my system from updating time. Once I configured the university ntp servers things were working again. Thanks for this tip! – Unpremeditated

This was also the cause of my problem, I was using an embedded device that had the wrong date! – Krute

Can someone explain why a git clone command cares about the system clock? – Picturesque

@Picturesque it's not git per say, it's the underlying SSL exchange. Git is built with SSL support. – Jeu

The time "looked" correct to the naked eye, and I tried apt-get install ntp with no luck, but eventually a restart did the trick. I'm assuming the clock was the problem, so thanks for the tip! I spent all morning trying to fix this and all I needed was a restart. Typical. – Dyslogistic

I fixed the time by sudo apt-get install ntpdate and sudo ntpdate ntp.ubuntu.com. – Besse

Answer 4

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"

Silviasilviculture

this worked for my vagrant vm. Thanks. – Spangle

Answer 5

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

Isar

Worked like a charm in linux mint 16 :) – Selfseeking

do you mean cert.pem or cert.crt or cert.pem.crt? – Rope

cert.pem should be renamed to cert.pem.crt – Isar

Answer 6

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.

Beadle

Thanks for this. If someone is having this issue using an old version of nodejs, it's because certificates are hardcoded in the source code and the new ISRG Root X1 certificate was only added in node v16.10.0 (github.com/nodejs/node/commit/…). You can either update node version, use node --use-openssl-ca (assuming openssl certificates are up to date) or set process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0 in your code. I guess this is going to cause some headaches today... – Ennui

For those having issues due to this, but unrelated to github, the following worked for me while following this comment https://mcmap.net/q/73177/-server-certificate-verification-failed-cafile-etc-ssl-certs-ca-certificates-crt-crlfile-none: sudo apt-get install apt-transport-https ca-certificates -y sudo update-ca-certificates – Irritated

EDIT: the nodejs version I mentionned (16.10.0) is wrong, this is actually the current node version – Ennui

@MaxAkn Updating Node js fixed the issue. Thanks!!! – Elyn

To echo @Irritated - updating libgnutls-openssl27 and openssl resolved the issue for me – Colcannon

I tried to upgrade openssl/gnutls, reinstall certs, but none of them works in my case(debian stretch). deselecting the expired cert in /etc/ca-certificates.conf followed by update-ca-certificates solve the issue. FYR – Frontier

Had to disable the expired cert on ubuntu bionic as suggested by @Frontier . The name of the cert was mozilla/DST_Root_CA_X3.crt. Prepend with ! in /etc/ca-certificates.conf and save, then run update-ca-certificates to disable the cert. I had also added the X1 cert linked in the answer to the ca-certificates beforehand, not sure if that is necessary. – Aphrodite

i had to do the same as @Aphrodite to get gitlab runners working, been messing with this for hours so you are a legend – Bullpen

Just as @Aphrodite mentioned, I had the same issue and it only worked once I disabled the expired certificate ! Unfortunately Im seeing this comment just after I managed to fixed myself... I wish I could had read this before, lost a lot of hours =( – Clemons

Answer 7

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.

Marquess

Yes! I had an instance of Ubuntu suspended in VirtualBox for a long time. The system clock did not sync for whatever reason when I unsuspended. VonC's answer seems knowledgeable, but I'm really glad I didn't have to run a bunch of security commands I don't understand. Check this first! – Seleucia

Thanks, that was my problem. To install & force ntp sync: sudo apt-get install -y ntp && sudo service ntp stop && sudo ntpd -gq && sudo service ntp start – Dollarfish

This was the cause of my problem on WSL, thank you ! – Barbette

Answer 8

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

Loopy

Nice addition with the GIT_CURL_VERBOSE. I didn't mention it in my answer. +1 – Shorts

Answer 9

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.

Naarah

I had problems in Raspberry Pi with both wget and curl showing this error. I fixed this issue by running only sudo dpkg-reconfigure ca-certificates and deselecting "DST Root CA X3" certificate. – Manas

This is enough in case system is quite current but for some reason automatic update didn't work. My answer is more focused to unsupported systems which 'just works'. – Naarah

Worked like magic on my Ubuntu 16.04.7 LTS. Thanks a lot ! – Cuprum

I may be stupid but I didn't find the option to unselect, I tried del and all the obvious ones, any idea ? – Buckeen

Do you mean keyboard key to unselect? Press space! If you do not see such option at all, may be its not relevant to your system. – Naarah

Answer 10

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.

Assize

Answer 11

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.

Undermine

I don't know if this works for anyone but I need "tee" to append the cert file as root: echo -n | openssl s_client -showcerts -connect yourserver.com:443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee -a /etc/ssl/certs/ca-certificates.crt – Appellee

In my case, the server has a valid certificate, but my database does not include it, with this command I resolved but I must to said that this command must be run with root privileges. – Sumerian

Answer 12

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

works for me.

Marleah

Answer 13

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.

Gimcrack

This solution solves my identical problem in Ubuntu 16.04. – Puto

What exactly do you mean with certificat chunks? The block between ---BEGIN CERTIFICATE--- and --- END CERTIFICATE ---? – Dolt

Answer 14

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.

Intersexual

Simple and easy solution. – Cripps

this worked, jessie still had openssl 1.0.1 as default version, but one from back ports worked – Naarah

Answer 15

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'

Crinkle

Answer 16

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

Impeachment

Same can be caused if the server is not configured properly with all SSL CA chain. – Impeachment

Chain issues can be the cause, as abcdef12 commented. I had this problem with git 1.9.1 - the server was sending the cert chain: #0 server cert; #1 server cert (again); #2 signer cert. The duplicate in the chain was the reason git didn't like it. – Valvulitis

Answer 17

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/

Spacious

This helped me but would you explain what this does? – Gombosi

this also helped me with seemingly unrelated netradio url not being playable from mpd. Curl was unhappy and it looks like it was related to this DST_Root_CA_X3.crt – Otocyst

helped me with part of upgrade problem with Gemini PDA debian – Shinto

Answer 18

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.

Isooctane

Answer 19

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/

Tailwind

Answer 20

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

Telencephalon

Answer 21

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"

Synchronic

Answer 22

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*

Kaifeng

I also faced same situation, where my gitlab server is using Let's Encrypt. However Let's Encrypt's root certificate expired previously: letsencrypt.org/ja/docs/… . The library I installed in my case is: apt install libgnutls-openssl27 . – Doubleacting

Answer 23

I know this is old, but now and then the error pop up again. If you are sure you can trust your local installation, you can simply add: GIT_SSL_NO_VERIFY: "true" in your variables section. In this way you simply disable the certificate validation.

This solution is similar to the one proposed here but it applies only to the current git tree and not the global git configuration.

Pig

But... I just spent part of this morning editing another answer to make clear that disabling SSL check is a bad idea?! As seen on Twitter. – Shorts

Answer 24

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.

Spherulite

Answer 25

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

Palmary

Answer 26

I encountered the same error when trying to clone something over into Windows WSL. turns out this was due to the clock being out of sync. Here is the command to re-sync the clock. the error was raised because the time on the server was different from the one on my machine.

sudo hwclock -s

Attaboy

I had the same issue with WSL. It saved my day! Thanks a lot ! – Poetics

Answer 27

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

Tella

Answer 28

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

Francoisefrancolin

Better to use the command line git config http.sslVerify false. Are you suggesting edit Git config on per-repository basis, not globally as suggested by @romain-vdk ? – Shue

Answer 29

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
  

Helen

Answer 30

This might sound trivial; however, correcting my date, solved the issue. Check if your date (esp.) and time are correct.

Lawhorn

Answer 31

In my case I have received this message, when I set on purpose my local laptop timezone (Ubuntu) on a future date. Once I set it correctly I was able to use git push.

It can be also a datetime issue on your local environment.

Good luck!

Organza

Answer 32

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.

Tiossem

Answer 33

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

Standford

Answer 34

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.

Remarkable

Answer 35

I know there are a lot of answers already. Just for those who use a private network, like Zscaler or so, this error can occur if your rootcert needs to be updated. Here a solution on how this update can be achieve if using WSL on a Windows machine:

#!/usr/bin/bash

# I exported the Zscaler certifcate out of Microsoft Cert Manager.  It was located under 'Trusted Root Certification > Certificates' as zscaler_cert.cer.
# Though the extension is '.cer' it really is a DER formatted file.
# I then copied that file into Ubuntu running in WSL.

# Convert DER encoded file to CRT.
openssl x509 -inform DER -in zscaler_cert.cer -out zscaler_cert.crt

# Move the CRT file to /usr/local/share/ca-certificates
sudo mv zscaler_cert.crt /usr/local/share/ca-certificates

# Inform Ubuntu of new cert.
sudo update-ca-certificates 

Molybdous

Answer 36

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

Jaye

Thank you for contributing to the Stack Overflow community. This question already has quite a few answers—including one that has been extensively validated by the community. Are you certain your approach hasn’t been given previously? If so, it would be useful to explain how your approach is different, under what circumstances your approach might be preferred, and/or why you think the previous answers aren’t sufficient. Can you kindly edit your answer to offer an explanation? – Capitalist

duplicate of stackoverflow.com/a/72000636 – Laureate

Answer 37

Problem Statement: "I encountered an issue while trying to clone a new Git repository on my Linux system. Initially, I attempted to clone using the HTTPS link, but I faced difficulties

ERROR: "server certificate verification failed. CAfile: none CRLfile: none". The cloning process was not successful, and I was stuck."

Solution: "After some investigation, I found a solution that resolved the problem. Here's a step-by-step guide on how I resolved the issue by switching from HTTPS to SSH:

Verify SSH Key Setup:

Ensure that your SSH key is set up correctly on your Linux system. You can check this by running the following command in your terminal:

ssh -T [email protected]

This command tests if your SSH key is properly configured with GitHub. Switching from HTTPS to SSH:

Go to the GitHub repository you want to clone. Click on the "Code" button, and make sure the SSH option is selected (it usually starts with [email protected]:). Copy the SSH URL. Clone the Repository:

Open your terminal. Navigate to the directory where you want to clone the repository. Use the following command to clone the repository with the SSH link:

git clone <SSH_URL>

Replace <SSH_URL> with the copied SSH URL from GitHub. Test the Clone:

After the cloning process is complete, navigate into the cloned directory. Verify that everything is working as expected. By switching from HTTPS to SSH and ensuring the correct SSH key setup, I was able to successfully clone the Git repository on my Linux system. This solution might be helpful for others facing a similar issue."

Dorelle