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

For those having the error since yesterday it's a Let's Encrypt root CA that has expired, check my answer here https://stackoverflow.com/a/69403278/11343 — CharlesB, Oct 01 '21 at 09:06
@CharlesB thank you!! that is six billionty very frustrating hours i don't need to spend searching for why this suddenly happens XP — Janna Maas, Oct 05 '21 at 07:53
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 — Tofandel, Oct 05 '21 at 12:46
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. — masterxilo, Oct 05 '21 at 17:56
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` — Delthas, Oct 19 '21 at 14:32
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. — smwikipedia, Jun 28 '22 at 03:08
Read this article, which provides a step-by-step guide on installing an SSL certificate, hope this article is helpful: https://noorui.com/blog/how-to-install-free-ssl-certificate-for-your-website-by-cpanel-terminal — Mohammed Rashad, Aug 15 '22 at 12:06

score 584 · Answer 1 · edited Oct 06 '21 at 09:59

584

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

edited Oct 06 '21 at 09:59

Pezo

1,458
9
15

answered Jan 17 '14 at 08:47

VonC

1,262,500
529
4,410
5,250

11

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 – uli_1973 Jul 08 '15 at 15:28
1

How do you find the git install folder? – Bhargav Jan 29 '16 at 05:45
1

@Bhargav it depends on your OS. On Linux, you can do a `which git`. – VonC Jan 29 '16 at 05:52
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 – a1an Jun 13 '17 at 13:36
Moreover the command to get the certificate does not produce any result (hangs). Disabling certificate verification works (even if insecure) – a1an Jun 13 '17 at 13:54
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 – emmdee Jan 10 '18 at 20:47
@emmdee Maybe because that certificate was not installed (https://askubuntu.com/a/859887/5470), but was present in the browser internal certificate store? – VonC Jan 10 '18 at 20:52
Interestingly, this worked for a corporate server before, but then failed again... in googling around, I found [this post](https://blogs.msdn.microsoft.com/phkelley/2014/01/20/adding-a-corporate-or-self-signed-certificate-authority-to-git-exes-store/), 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? – Hendy Apr 24 '18 at 00:20
@Hendy Not sure, but yes, intermediate and root CA needs to be there in the crt file. – VonC Apr 24 '18 at 04:33
@VonC 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! – Hendy Apr 25 '18 at 20:24
1

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. – garethTheRed May 26 '21 at 05:00
@garethTheRed good point. How to add only root CA, in the context of this question? – VonC May 26 '21 at 05:12
1

@VonC - please see [below](https://stackoverflow.com/a/67698986/1925616). Let me know your thoughts :-) – garethTheRed May 26 '21 at 05:31
How "to check the web certificate used for your gitLab server" ? – Ekaterina Ivanova iceja.net Jan 27 '22 at 06:32
@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. – VonC Jan 27 '22 at 08:16
That resolve my probleme : git config --global http.sslverify false – Mahefa May 13 '22 at 12:07
@Mahefa It does indeed, for testing. But disabling SSL verification is considered as a bad practice, and should be avoided if possible. – VonC May 13 '22 at 12:30

score 383 · Answer 2 · edited Mar 07 '17 at 17:50

383

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.

edited Mar 07 '17 at 17:50

ceejayoz

176,543
40
303
368

answered Mar 18 '14 at 10:57

Afzal Masood

4,293
1
14
18

97

Not downvoting because it's a workaround for when you know what you are doing. However, strongly recommend against this in the general case. – tripleee Mar 27 '14 at 07:29
10

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. – srcspider May 28 '14 at 11:39
1

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 – Desu May 21 '15 at 04:54
25

Only worked for me with `git config --global http.sslverify false` – Dinei May 03 '17 at 18:30
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? – Nenad Bulatović Dec 07 '18 at 15:48
1

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. – ascendants Mar 18 '20 at 19:42
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. – LCoelho Jan 05 '21 at 12:56

score 182 · Answer 3 · edited Jan 06 '17 at 01:49

182

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

edited Jan 06 '17 at 01:49

DaAwesomeP

585
5
18

answered Apr 08 '14 at 18:33

davidthings

1,920
1
11
3

5

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! – Kyle Mar 09 '15 at 16:51
3

This was also the cause of my problem, I was using an embedded device that had the wrong date! – Shervin Emami Feb 02 '16 at 08:33
Can someone explain why a `git clone` command cares about the system clock? – Katu Mar 30 '17 at 14:05
1

@Katu it's not `git` per say, it's the underlying SSL exchange. Git is built with SSL support. – Yvan Aug 22 '17 at 10:21
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. – Ariel Aug 25 '17 at 09:12
I fixed the time by `sudo apt-get install ntpdate` and `sudo ntpdate ntp.ubuntu.com`. – jiashenC Sep 10 '18 at 19:45

Romain VDK · Answer 4 · 2021-11-18T12:42:45.450

137

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"

edited Nov 18 '21 at 12:42

answered Oct 09 '17 at 12:33

Romain VDK

1,798
1
11
9

this worked for my vagrant vm. Thanks. – Malaji Nagaraju May 10 '22 at 05:15

score 56 · Answer 5 · answered Jun 30 '14 at 14:23

56

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

answered Jun 30 '14 at 14:23

Nikolay Ruban

981
9
11

2

Worked like a charm in linux mint 16 :) – greuze Jul 09 '14 at 12:22
do you mean cert.pem or cert.crt or cert.pem.crt? – Moses Liao GZ Feb 24 '17 at 07:03
1

cert.pem should be renamed to cert.pem.crt – Nikolay Ruban Feb 27 '17 at 12:01

CharlesB · Answer 6 · 2021-10-03T08:24:30.510

41

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.

edited Oct 03 '21 at 08:24

answered Oct 01 '21 at 09:03

CharlesB

86,532
28
194
218

4

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 (https://github.com/nodejs/node/commit/6331b63ce0e99bc1e5de4e21ea0c9da9df8ab759). 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... – Max Oct 01 '21 at 09:23
7

For those having issues due to this, but unrelated to github, the following worked for me while following this comment https://stackoverflow.com/a/24492364/14633782: `sudo apt-get install apt-transport-https ca-certificates -y sudo update-ca-certificates` – Keipi Oct 01 '21 at 10:17
EDIT: the nodejs version I mentionned (16.10.0) is wrong, this is actually the current node version – Max Oct 01 '21 at 10:37
@MaxAkn Updating Node js fixed the issue. Thanks!!! – Towfiq Oct 03 '21 at 03:53
4

To echo @Keipi - updating `libgnutls-openssl27` and `openssl` resolved the issue for me – Ed Spencer Oct 05 '21 at 12:04
2

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 – dproc Oct 18 '21 at 07:41
5

Had to disable the expired cert on ubuntu bionic as suggested by @dproc . 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. – Vertganti Oct 19 '21 at 06:59
1

i had to do the same as @Vertganti to get gitlab runners working, been messing with this for hours so you are a legend – rchatburn Oct 19 '21 at 10:23
Just as @Vertganti 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 =( – Eduardo Lima Jan 11 '23 at 16:44

mycowan · Answer 7 · 2019-12-22T15:00:37.793

40

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.

edited Dec 22 '19 at 15:00

answered Sep 07 '15 at 08:10

mycowan

993
8
18

2

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! – AndyJost Feb 24 '19 at 20:17
1

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` – masterxilo Mar 05 '21 at 17:33
1

This was the cause of my problem on WSL, thank you ! – bathal Jul 09 '23 at 15:35

score 35 · Answer 8 · answered Apr 15 '14 at 15:12

35

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

answered Apr 15 '14 at 15:12

Tobu

24,771
4
91
98

4

Nice addition with the `GIT_CURL_VERBOSE`. I didn't mention it in my answer. +1 – VonC Apr 15 '14 at 15:29

Arunas Bartisius · Answer 9 · 2021-10-19T18:08:54.417

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.

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. — Kar.ma, Oct 19 '21 at 16:14
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'. — Arunas Bartisius, Oct 19 '21 at 17:49

garethTheRed · Answer 10 · 2021-05-26T08:18:23.980

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.

score 21 · Answer 11 · edited Aug 30 '16 at 10:51

21

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.

edited Aug 30 '16 at 10:51

Maximilian Ast

3,369
12
36
47

answered Aug 30 '16 at 09:10

phiphu

211
2
4

2

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 – ywu May 20 '17 at 02:02
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. – hermeslm Jun 18 '18 at 18:45

score 16 · Answer 12 · edited Apr 26 '22 at 04:03

16

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

works for me.

edited Apr 26 '22 at 04:03

General Grievance

4,555
31
31
45

answered Apr 25 '22 at 13:48

Vlad Pavlovski

1,582
1
14
10

score 14 · Answer 13 · edited Jun 26 '19 at 16:45

14

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.

edited Jun 26 '19 at 16:45

Laurenz Albe

209,280
17
206
263

answered Jun 26 '19 at 16:26

mindcoder

377
3
11

1

This solution solves my identical problem in Ubuntu 16.04. – user3072843 Aug 10 '19 at 21:18
1

What exactly do you mean with *certificat chunks*? The block between `---BEGIN CERTIFICATE---` and `--- END CERTIFICATE ---`? – B--rian Feb 27 '20 at 08:37

score 12 · Answer 14 · answered Oct 05 '21 at 03:40

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.

this worked, jessie still had openssl 1.0.1 as default version, but one from back ports worked — Arunas Bartisius, Oct 13 '21 at 21:39

score 10 · Answer 15 · answered Feb 07 '15 at 17:23

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'

score 8 · Answer 16 · answered Jun 06 '15 at 07:19

8

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

answered Jun 06 '15 at 07:19

abcdef12

1,033
1
11
22

1

Same can be caused if the server is not configured properly with all SSL CA chain. – abcdef12 Aug 12 '15 at 22:54
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. – jah Nov 07 '16 at 20:51

score 8 · Answer 17 · answered Oct 04 '21 at 12:41

8

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/

answered Oct 04 '21 at 12:41

Sylvain Tch

131
1
5

This helped me but would you explain what this does? – jedi Oct 05 '21 at 09:17
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` – nass Oct 20 '21 at 19:16
helped me with part of upgrade problem with Gemini PDA debian – jirimertin Oct 16 '22 at 19:10

user2851100 · Answer 18 · 2021-10-19T03:36:27.070

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.

score 4 · Answer 19 · answered Jul 14 '20 at 13:30

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/

score 4 · Answer 20 · answered Jan 23 '21 at 10:13

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

score 3 · Answer 21 · answered Mar 24 '15 at 19:03

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"

score 3 · Answer 22 · answered Mar 14 '22 at 15:13

3

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.

answered Mar 14 '22 at 15:13

Denis Pitzalis

2,800
1
15
12

But... I just spent part of this morning editing [another answer](https://stackoverflow.com/a/60025240/6309) to make clear that disabling SSL check is a bad idea?! As [seen on Twitter](https://twitter.com/VonC_/status/1503267353781575685). – VonC Mar 14 '22 at 15:16

score 2 · Answer 23 · answered Nov 20 '19 at 00:18

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.

score 2 · Answer 24 · answered Jan 25 '22 at 09:34

2

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*

answered Jan 25 '22 at 09:34

Honza Vojtěch

685
1
7
27

I also faced same situation, where my gitlab server is using Let's Encrypt. However Let's Encrypt's root certificate expired previously: https://letsencrypt.org/ja/docs/dst-root-ca-x3-expiration-september-2021/ . The library I installed in my case is: `apt install libgnutls-openssl27` . – 千木郷 Jan 30 '22 at 15:15

score 2 · Answer 25 · answered Mar 04 '22 at 10:13

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

score 1 · Answer 26 · answered Jul 26 '14 at 16:50

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

score 1 · Answer 27 · answered Mar 14 '16 at 16:12

1

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

answered Mar 14 '16 at 16:12

Mickael L

57
1

1

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 ? – ahogen Jan 03 '20 at 22:02

StefTN · Answer 28 · 2021-05-28T14:02:08.277

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

score 1 · Answer 29 · answered Aug 05 '22 at 15:30

1

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

answered Aug 05 '22 at 15:30

Chukwunazaekpere

906
1
6
13

score 1 · Answer 30 · answered May 10 '23 at 09:05

1

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

answered May 10 '23 at 09:05

niqeel

29
4

I had the same issue with WSL. It saved my day! Thanks a lot ! – sweetdream Jun 29 '23 at 09:27

score 0 · Answer 31 · edited Jun 12 '19 at 12:44

0

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.

edited Jun 12 '19 at 12:44

Kamran

782
10
35

answered Jun 12 '19 at 10:05

shambhu

1

score 0 · Answer 32 · answered Sep 20 '21 at 04:54

0

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

answered Sep 20 '21 at 04:54

Leo

2,775
27
29

score 0 · Answer 33 · answered Feb 09 '22 at 18:32

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.

score 0 · Answer 34 · answered Jul 08 '22 at 06:41

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

score 0 · Answer 35 · answered Jun 15 '23 at 22:49

0

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

answered Jun 15 '23 at 22:49

Alex

837
8
9

1

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? – Jeremy Caney Jun 22 '23 at 00:23
duplicate of https://stackoverflow.com/a/72000636/ – karel Jun 22 '23 at 10:16

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

35 Answers35

Current system

Outdated system

Linked

Related