curl: (60) SSL certificate problem: unable to get local issuer certificate

Question

root@sclrdev:/home/sclr/certs/FreshCerts# curl --ftp-ssl --verbose ftp://{abc}/ -u trup:trup --cacert /etc/ssl/certs/ca-certificates.crt
* About to connect() to {abc} port 21 (#0)
*   Trying {abc}...
* Connected to {abc} ({abc}) port 21 (#0)
< 220-Cerberus FTP Server - Home Edition
< 220-This is the UNLICENSED Home Edition and may be used for home, personal use only
< 220-Welcome to Cerberus FTP Server
< 220 Created by Cerberus, LLC
> AUTH SSL
< 234 Authentication method accepted
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Burt

possible duplicate of SSL certificate issue: unable to get local issuer certificate on payapl ipn verification – Manipulator

I've had similar issue. This worked for me stackoverflow.com/a/29649024 – Sirius

In my case, superuser.com/a/719047/137881 helped. – Ditty

// , In my case, I got this error from making curl requests to the HashiCorp Vault server until I installed an X509 certificate with the end-entity/Intermediates/root only in reverse order, each of which was Base64 encoded. – Thunell

// , What research did you do on this before copying the error into here? – Thunell

check this use for get solution: stackoverflow.com/questions/28858351/… – Nawrocki

You may be in a proxy internet connection if you are working in an organization instead of a personal computer. Ask for a static IP if any of the possible solution does not work. – Zachariah

Answer 1

It is failing as cURL is unable to verify the certificate provided by the server.

There are two options to get this to work:

1. Use cURL with -k option which allows curl to make insecure connections, that is cURL does not verify the certificate.

2. Add the root CA (the CA signing the server certificate) to /etc/ssl/certs/ca-certificates.crt

You should use option 2 as it's the option that ensures that you are connecting to secure FTP server.

Wolk

I added my rootCA.pem file inside :- root@sclrdev:/home/certs/FreshCerts# ll /etc/ssl/certs/rootCA.pem -rwxrwxrwx 1 root root 1302 Jul 8 00:09 /etc/ssl/certs/rootCA.pem* Even I verified the ServerCertificate.pem file with my rootCA.pem:- root@sclrdev:/home/certs/FreshCerts# openssl verify -CAfile rootCA.pem ../ServerCertificate.pem ServerCertificate.pem: OK And also the contents of rootCA.pem inside ca-certificates.crt. root@sclrdev:/home/sclr/subhendu/certs/FreshCerts# ll /etc/ssl/certs/ca-certificates.crt -rw-r--r-- 1 root root 247945 Jul 8 00:10 /etc/ssl/certs/ca-certificates.crt – Burt

I am not able to figure out where am I going wrong. In WireShark traces, I get the following error :- Client Hello Server Hello, Certificate, Server Hello Done Alert (level : Fatal, Description: unknown CA (48)) Can you please guide me and help me out in this ? – Burt

The way openssl works is it tries to complete teh certificate chain during verification. Is your server certificate signed by an intermiate CA and not a root CA. for example – Wolk

My certificate is signed by root CA only. – Burt

Sorry previous comment got posted before I completed. Is your server certificate signed by an intermediate CA and not a root CA. For example if your certificate chain is server_cert, signed by intermediate_cert, signed by rootCA you will get errors if openssl cannot for the entire chain. The way openssl works is it tries to form a complete certificate chain (server cert to root CA) during verification. If the server does not provide the intermediate CA certs, openssl looks it up in the certificate store. If it cant it will throw an unknown CA error. – Wolk

But if I have signed my Server Certificate with only my root CA and not any intermediate CA, then I think it should not search for any chain. Moreover, I have verified my ServerCertificate & rootCA through openssl commands as mentioned above. Can you please tell if there's something wrong in my understanding or if there's any mistake which I'm doing in testing ? – Burt

Referred to the following page for creating certs :- theheat.dk/blog/?p=1023 Referred to the following sections :- 1)Create the CA 2)Create a SSL Server certificate – Burt

Looks like you are doing the right steps. One last suggestion. Does your openssl verify command that you executed with rootCA.pem also work when you use ca-certificates.crt. I want to make sure that ca-certificates.crt is in the correct PEM format. – Wolk

Yes. It works fine with ca-certificates.crt root@sclrdev:/home/certs/FreshCerts# openssl verify -CAfile ca-certificates.crt ServerCertificate.pem ServerCertificate.pem: OK – Burt

Is any other possible checklist which I'm missing out ? – Burt

I'm using FileZilla as my server here. – Burt

The only other thing I can think of if to ensure using a packet capture that the server certificate you are testing with is the some one presented by the server. You could also look at the certs by using: openssl s_client -connect <server>:443 -showcerts – Wolk

I got some error :- root@sclrdev:~# openssl s_client -connect <server_ip>:21 -showcerts CONNECTED(00000003) 3074050248:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:766: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 225 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- I'm not sure what this exactly means ? – Burt

You may be in a proxy internet connection if you are working in an organization instead of a personal computer. Ask for a static IP if the solution does not work. – Zachariah

-k works for me – Turkmen

Answer 2

Relating to 'SSL certificate problem: unable to get local issuer certificate' error. It is important to note that this applies to the system sending the CURL request, and NOT the server receiving the request.

1. Download the latest cacert.pem from https://curl.se/ca/cacert.pem

2. Add the '--cacert /path/to/cacert.pem' option to the curl command to tell curl where the local Certificate Authority file is.

3. (or) Create or add to a '.curlrc' file the line: cacert = /path/to/cacert.pem See 'man curl', the section about the '-K, --config <file>' section for information about where curl looks for this file.

4. (or if using php) Add the following line to php.ini: (if this is shared hosting and you don't have access to php.ini then you could add this to .user.ini in public_html).

curl.cainfo="/path/to/downloaded/cacert.pem"

Make sure you enclose the path within double quotation marks!!!

5. (perhaps also for php) By default, the FastCGI process will parse new files every 300 seconds (if required you can change the frequency by adding a couple of files as suggested here https://ss88.uk/blog/fast-cgi-and-user-ini-files-the-new-htaccess/).

Tammany

What is the difference between openssl.cafile and curl.cainfo in php.ini? Both seem to work well (on windows). – Amy

The first relates to certification of operations performed using the OpenSSL library; the second to requests made using cURL – How

This may also happen at the server when an intermediary cert is missing. – Enthrall

Actually I struggled for an hour as I did not write path inside quotes. So please take a note here curl.cainfo="/path/to/downloaded/cacert.pem" // Do not forget to write between quotes – Tyrant

I don't see any reference in the question to PHP. Why te references in the answer? If the question has been edited then could the answer be edited to reflect the command line now being used? – Hirundine

@Hirundine While the question doesn't mention PHP, this comes up as the #1 search result in Google for the specific error message generated by PHP. So, maybe it doesn't specifically answer OP's question, but it seems it's still useful to the community. – Leavenworth

This answer was misleading to me as it is a solution related to PHP – Spillage

Thanks for this, reminded me to put the line in php.ini as I was struggling to get it working. – Reception

Is it .user.ini or user.ini? I mean you have a dot before file name. – Skysweeper

In my case , in addition to restart services it was necessary to restart the pc :| – Scott

You may be in a proxy internet connection if you are working in an organization instead of a personal computer. Ask for a static IP if the solution does not work. – Zachariah

But is this errorMsg "part of" the response or is it an errorMsg by Curl? – Thankless

Thanks for the added Hint: applies to he system sending the CURL request. that helped me very much – Mellie

Edited answer to give information about solving the problem for curl (by specifying a local cacert.pem file) – Mellins

I also get this error with a server - even after downloading the cacert.pem as described. Qualys SSLLabs reports "This server's certificate chain is incomplete." - among other issues. It might make sense to point out there are several possible causes for this error (client side or server side). This answer helps to narrow it down, though. – Nomen

why the file I downloaded is cacert.cer, not cacert.pem? – Laddie

thank you. I follow steps 1 and 2, and my curl look like this --> curl -v --cacert /Users/build/cacert.pem --upload-file ./release.apk your-url-target/sit.apk --http1.1 – Dignity

The solution that worked for me was to generate a full chain cert including Root Certificate at sslmate.com >In Nginx configuration file replace the ssl_certificate file with the new cert from sslmate. >Restart Nginx – Sices

Answer 3

I have solved this problem by adding one line code in cURL script:

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

Warning: This makes the request absolute insecure (see answer by @YSU)!

Furnace

This may help to circumvent the problem. But it totally misses the idea of https and the certification system. – Lupulin

Works! Nice quick n dirty bypass if you don't care about the certificate – Modernity

This makes it completely insecure. – Loyalist

I was facing this issue on my local server though the same code worked fine on staging server. Fine for me as it was on local. Thanks – Esthonia

add this check to ensure you only use it with local server if( stristr("127.0.0.1",$_SERVER["SERVER_NAME"] ) || stristr("localhost",$_SERVER["SERVER_NAME"] )) curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); – Stockdale

Bash equivalent of this is the -k parameter. – Integrity

When I tried with this command: ./curl -k https://www.google.com --libcurl google-sec.c the generated c file contained the following also:curl_easy_setopt(hnd, CURLOPT_SSL_VERIFYPEER, 0L); curl_easy_setopt(hnd, CURLOPT_SSL_VERIFYHOST, 0L); – Serif

Good solution when working in local environment. Totally did it for me. – Barthol

which is a bad practice. acceptable on staging / test but not on production environments. – Extremism

Answer 4

For me, simple install of certificates helped:

sudo apt-get install ca-certificates

Morbid

For example some small docker containers might not have this installed and there is no point to troubleshot anything else when the whole package is not present. – Votary

Answer 5

In my case it turned out to be a problem with the installation of my certificate on the service I was trying to consume with cURL. I failed to bundle/concatenate the intermediate and root certificates into my domain certificate. It wasn't obvious at first that this was the problem because Chrome worked it out and accepted the certificate in spite of leaving out the intermediate and root certificates.

After bundling the certificate, everything worked as expected. I bundled like this

$ cat intermediate.crt >> domain.crt

And repeated for all intermediate and the root certificate.

Ketonuria

I had a similar problem, except I didn't have my Apache SSLCertificateChainFile set to the correct certificate. – Melessa

Note that if you do this, and the crt's you're adding don't have a trailing newline, then you'll have lines like -----END CERTIFICATE----------BEGIN CERTIFICATE----- in your bundle, and you'll get the obscure error: curl: (77) error setting certificate verify locations – Lustral

I'm using letsencrypt certificates but deployed only the cert and private key to the server. Chrome and curl on my computer wasn't complaining, however a nodejs app that I was building didn't accept the certificate. Deploying the fullchain to the server fixed the issue! Thank you for pointing the right direction! – Telegraphy

In my case (certificate from comodo), they sent the intermediate certificates as my-domain.ca-bundle. I had to append that to my-domain.crt. Thanks! – Bradstreet

it work for me.thanks I get the domain cert,intermediate cert,root cert from digitcert.but only domain cert is referred in nginx conf – Dodecagon

Answer 6

Had this problem after install Git Extensions v3.48. Tried to install mysysgit again but same problem. At the end, had to disable (please consider security implications!) Git SSL verification with:

git config --global http.sslVerify false

but if you have a domain certificate better add it to (Win7)

C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt

Latakia

Works, but feels like hidding the symptom, not curing the disease. – Courcy

Disabling SSL-verification is very dangerous – Reformatory

You could do without --global to have SSL only disabled for the repository where you have issues. See groups.google.com/forum/#!topic/git-for-windows/mlqn5J4OLlw for a discussion on the current necessary crt files. – Talcahuano

Answer 7

It is most likely a missing cert from the server.

Root->Intermediate->Server

A server should send the Server & Intermediate as a minimum.

Use openssl s_client -showcerts -starttls ftp -crlf -connect abc:21 to debug the issue.

If only one cert is returned (either self signed, or issued), then you must choose to either:

1. have the server fixed
2. trust that cert and add it to your CA cert store (not the best idea)
3. disable trust, e.g. curl -k (very bad idea)

If the server returned, more than one, but not including a self signed (root) cert:

1. install the CA (root) cert in your CA store for the this chain, e.g. google the issuer. (ONLY if you trust that CA)
2. have the server fixed to send the CA as part of the chain
3. trust a cert in the chain
4. disable trust

If the server returned a root CA certificate, then it is not in your CA store, your options are:

1. Add (trust) it
2. disable trust

I have ignored expired / revoked certs because there were no messages indicating it. But you can examine the certs with openssl x509 -text

Given you are connecting to a home edition (https://www.cerberusftp.com/support/help/installing-a-certificate/) ftp server, I am going to say it is self signed.

Please post more details, like the output from openssl.

Anderegg

I'm not sure if I am wrong, but According to the manual of openssl the -showcerts flag should show only the sent remote certs. So if you test with that, it seems that even if you have the whole chain local and correct, openssl could output an error (since you only look at the sent certificates chain which could be incomplete). I would test with curl -vvv www.google.ch:443 to test if the local store is already correct and openssl -showcerts for the sent chain. Until now, I did not find any other solution to distinguish and check between local and remote. – Monophony

You could also use testssl.h to check whether the fullchain cert is there – Forcible

Answer 8

We ran into this error recently. Turns out it was related to the root cert not being installed in the CA store directory properly. I was using a curl command where I was specifying the CA dir directly. curl --cacert /etc/test/server.pem --capath /etc/test ... This command was failing every time with curl: (60) SSL certificate problem: unable to get local issuer certificate.

After using strace curl ..., it was determined that curl was looking for the root cert file with a name of 60ff2731.0, which is based on an openssl hash naming convetion. So I found this command to effectively import the root cert properly:

ln -s rootcert.pem `openssl x509 -hash -noout -in rootcert.pem`.0

which creates a softlink

60ff2731.0 -> rootcert.pem

curl, under the covers read the server.pem cert, determined the name of the root cert file (rootcert.pem), converted it to its hash name, then did an OS file lookup, but could not find it.

So, the takeaway is, use strace when running curl when the curl error is obscure (was a tremendous help), and then be sure to properly install the root cert using the openssl naming convention.

Faber

Phew, it did help. To elaborate a bit what helped me: a) run strace curl... b) look for failed stat() with something-hex.0 c) googled for something-hex, found corresponding cert d) put found cert into /usr/local/share/ca-certificates/ (with *.crt extension, as *.pem didn't work) e) run update-ca-certificates . Then Bingo! - necessary symlink was automagically created in /usr/lib/ssl/certs/ – Deceive

great explanation here stackoverflow.com/questions/9879688/… – Horsewhip

I've been running into this same problem with MariaDB w/ two-way SSL. Apparently, MariaDB (and presumably MySQL) follow the same rules as curl, despite that it's seemingly undocumented---CA cert filename must follow the openssl hash naming convention if you specify a ca directory via ssl_capath (option file) or --ssl-capath (client command line arguments). Your 7-year-old answer saved me. – Flection

Answer 9

It might be sufficient to just update the list of certificates

sudo update-ca-certificates -f

update-ca-certificates is a program that updates the directory /etc/ssl/certs to hold SSL certificates and generates ca-certificates.crt, a concatenated single-file list of certificates.

Uruguay

did it and everything is done after running it. But curl not working. still the same error. – Bedstead

I did command, and it didn't help, and I couldn't believe that I have to do everything above. And then your answer... Thanks for '-f' flag. – Kourtneykovac

Answer 10

I have encountered this problem as well. I've read this thread and most of the answers are informative but overly complex to me. I'm not experienced in networking topics so this answer is for people like me.

In my case, this error was happening because I didn't include the intermediate and root certificates next to the certificate I was using in my application.

Here's what I got from the SSL certificate supplier:

- abc.crt
- abc.pem
- abc-bunde.crt

In the abc.crt file, there was only one certificate:

-----BEGIN CERTIFICATE-----
/*certificate content here*/
-----END CERTIFICATE-----

If I supplied it in this format, the browser would not show any errors (Firefox) but I would get curl: (60) SSL certificate : unable to get local issuer certificate error when I did the curl request.

To fix this error, check your abc-bunde.crt file. You will most likely see something like this:

-----BEGIN CERTIFICATE-----
/*additional certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*other certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*different certificate content here*/
-----END CERTIFICATE-----

These are your Intermediate and root certificates. Error is happening because they are missing in the SSL certificate you're supplying to your application.

To fix the error, combine the contents of both of these files in this format:

-----BEGIN CERTIFICATE-----
/*certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*additional certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*other certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*different certificate content here*/
-----END CERTIFICATE-----

Note that there are no spaces between certificates, at the end or at the start of the file. Once you supply this combined certificate to your application, your problem should be fixed.

Biotic

This solved my problem. Didn't realize having an empty line between certificates was bad. – Interradial

After reading this i had regenerated the .pfx file for the server using -certfile option instead of -CAfile. It fixed the issue when invoking server api using curl. e.g. openssl pkcs12 -export -out a.pfx -inkey privateKey.pem -in uri.crt -certfile certs.ca-bundle – Phototelegraphy

Answer 11

1. Download https://curl.haxx.se/ca/cacert.pem

2. After download, move this file to your wamp server.

   For exp: D:\wamp\bin\php\

3. Then add the following line to the php.ini file at the bottom.

curl.cainfo="D:\wamp\bin\php\cacert.pem"

4. Now restart your wamp server.

Rhodian

Answer 12

According to cURL docs you can also pass the certificate to the curl command:

Get a CA certificate that can verify the remote server and use the proper option to point out this CA cert for verification when connecting. For libcurl hackers: curl_easy_setopt(curl, CURLOPT_CAPATH, capath);

With the curl command line tool: --cacert [file]

---

For example:

curl --cacert mycertificate.cer -v https://www.stackoverflow.com

Showily

Answer 13

Try reinstalling curl in Ubuntu, and updating my CA certs with sudo update-ca-certificates --fresh which updated the certs

Throttle

Answer 14

If you just want to test it out then pass the --insecure along with the curl command just to skip the validation.

Forbis

Answer 15

Mine worked by just adding -k to my curl. No need to complicate things.

curl -LOk https://dl.k8s.io/release/v1.20.0/bin/linux/amd64/kubectl

Quench

This is just skipping the security thing. Not a real solution. – Thearchy

this is a temporary workaroudn not a solution ... the -k or --ignore means not security is enforced / checked... so it goes against the main purpose of using certificates and TLS – Corm

Answer 16

Yes you need to add a CA certificate also. Adding a code snippet in Node.js for clear view.

var fs = require(fs)
var path = require('path')
var https = require('https')
var port = process.env.PORT || 8080;
var app = express();

https.createServer({
key: fs.readFileSync(path.join(__dirname, './path to your private key/privkey.pem')),
cert: fs.readFileSync(path.join(__dirname, './path to your certificate/cert.pem')),
ca: fs.readFileSync(path.join(__dirname, './path to your CA file/chain.pem'))}, app).listen(port)

Tyra

Answer 17

You have to change server cert from cert.pem to fullchain.pem
I had the same issue with Perl HTTPS Daemon:
I have changed:
SSL_cert_file => '/etc/letsencrypt/live/mydomain/cert.pem'
to:
SSL_cert_file => '/etc/letsencrypt/live/mydomain/fullchain.pem'

Somite

I encountered that problem when moving existing certificates to a CyberPanel hosting, and this is the way I managed to fix it. – Laruelarum

Answer 18

On windows I was having this problem. Curl was installed by mysysgit, so downloading and installing the newest version fixed my issue.

Otherwise these are decent instructions on how to update your CA cert that you could try.

Leash

Answer 19

Enter these two codes to disable the SSL certificate issue. it's worked for me after a lot of research I found this.

curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

Towns

where should I enter those lines? in what file? location? – Corneille

Seems to duplicate this (also questionable) answer from 2015 https://mcmap.net/q/18956/-curl-60-ssl-certificate-problem-unable-to-get-local-issuer-certificate – Bushmaster

Answer 20

My case was different. I'm hosting a site behind a firewall. The error was caused by pfSense.

Network layout: |Web Server 10.x.x.x| <-> |pfSense 49.x.x.x| <-> |Open Internet|

I accidentally found the cause, thanks to this answer.

---

All is well when I accessed my site from WAN.

However, when the site was accessed from inside LAN (e.g. when Wordpress made a curl request to its own server, despite using the WAN IP 49.x.x.x), it was served the pfSense login page.

I identified the certificate as pfSense webConfigurator Self-Signed Certificate. No wonder curl threw an error.

Cause: What happened was that curl was using the site's WAN IP address 49.x.x.x. But, in the context of the web server, the WAN IP was the firewall.

Debug: I found that I was getting the pfSense certificate.

Solution: On the server hosting the site, point its own domain name to 127.0.0.1

By applying the solution, curl's request was properly handled by the web server, and not forwarded to the firewall which responded by sending the login page.

Devoe

Answer 21

I intended to comment on Yuvik's answer but I lack enough reputation points.

When you import a .crt file to /usr/share/local/ca-certificates, it needs to be in the correct format. Some of these have been mentioned earlier, but no one has mentioned the need for only a new line character, and no one has collected a checklist, so I thought I would provide one while I'm at it.

1. The certificate needs to end in .crt. From Ubuntu's man page:

   Certificates must have a .crt extension in order to be included by update-ca-certificates

2. Certificate files in /usr/local/share/ca-certificates can only contain one certificate

3. Certificate files must end in a newline. update-ca-certificates will appear to work if each row contains, for example, a carriage return + a newline (as is standard in Windows), but once the certificate is appended to /etc/ssl/ca-certificates.crt, it still will not work. This specific requirement bit me as we're loading certificates from an external source.

Badtempered

Answer 22

On windows - if you want to run from cmd

> curl -X GET "https://some.place"

Download cacert.pem from https://curl.haxx.se/docs/caextract.html

Set permanently the environment variable:

CURL_CA_BUNDLE = C:\somefolder\cacert.pem

And reload the environment by reopening any cmd window in which you want to use curl; if Chocolatey is installed you can use:

refreshenv

Now try again

Reason for the trouble: https://laracasts.com/discuss/channels/general-discussion/curl-error-60-ssl-certificate-problem-unable-to-get-local-issuer-certificate/replies/95548

Redwood

Answer 23

This is ssh certificate store issue. You need to download the valid certificate pem file from target CA website, and then build the soft link file to instruct ssl the trusted certifacate.

openssl x509 -hash -noout -in DigiCert_Global_Root_G3.pem

you will get dd8e9d41

build solf link with hash number and suffix the file with a .0 (dot-zero)

dd8e9d41.0

Then try again.

Resnatron

Answer 24

So far, I've seen this issue happen within corporate networks because of two reasons, one or both of which may be happening in your case:

1. Because of the way network proxies work, they have their own SSL certificates, thereby altering the certificates that curl sees. Many or most enterprise networks force you to use these proxies.
2. Some antivirus programs running on client PCs also act similarly to an HTTPS proxy, so that they can scan your network traffic. Your antivirus program may have an option to disable this function (assuming your administrators will allow it).

As a side note, No. 2 above may make you feel uneasy about your supposedly secure TLS traffic being scanned. That's the corporate world for you.

Muskrat

Answer 25

Had that problem and it was not solved with newer version. /etc/certs had the root cert, the browser said everything is fine. After some testing I got from ssllabs.com the warning, that my chain was not complete (Indeed it was the chain for the old certificate and not the new one). After correcting the cert chain everything was fine, even with curl.

Jasik

Answer 26

Some systems may have this problem due to conda environment. If you have conda installed then disabling it may solve your problem. In my case when I deactivated conda this curl-SSL error was resolved. On ubuntu or MacOS try this command

conda deactivate

Darky

Answer 27

On Amazon Linux (CentOS / Red Hat etc) I did the following to fix this issue. First copy the cacert.pem downloaded from http://curl.haxx.se/ca/cacert.pem and put it in the /etc/pki/ca-trust/source/anchors/ directory. Then run the update-ca-trust command.

Here is a one liner taken from https://serverfault.com/questions/394815/how-to-update-curl-ca-bundle-on-redhat

curl https://curl.se/ca/cacert.pem -o /etc/pki/ca-trust/source/anchors/curl-cacert-updated.pem && update-ca-trust

However since curl was broken I actually used this command to download the cacert.pem file.

wget --no-check-certificate http://curl.haxx.se/ca/cacert.pem

Also if you were having trouble with php you may need to restart your web server service httpd restart for apache or service nginx restart for nginx.

Brail

Answer 28

I've been pulling my hair out over this issue for days on a Wordpress installation attempting to communicate with an internal ElasticSearch service via ElasticPress and a self-signed Root CA managed by AWS ACM PCA.

In my particular case, I was receiving a 200 OK response from the default cURL Transport as well as the expected body, but Wordpress was coming back with a WP_Error object as well that ElasticPress was picking up due to this certificate issue but never logging.

When it comes to Wordpress, there are two things worth noting:

1. The default cURL Transport for all wp_remote_* calls will look to a CA Bundle located in wp-includes/certificates/ca-bundle.crt. This bundle serves largely the same purpose as what's found under https://curl.haxx.se/docs/caextract.html, and will cover most use-cases that don't typically involve more exotic setups.
2. Action/Filter order matters in Wordpress, and in ElasticPress' case, many of its own internal functions leverage these remote calls. The problem is, these remote calls were being executed during the plugins_loaded lifecycle, which is too early for Theme logic to be able to override. If you're using any plugins that make external calls out to other services and you need to be able to modify the requests, you should take careful note as to WHEN these plugins are performing these requests.

What this means is that even with the right server setup, hooks, callbacks, and logic defined in your theme, you can still end up with a broken setup because the underlying plugin calls execute well before your theme loads and will never be able to tell Wordpress about the new certificates.

In the context of Wordpress applications, there are only two ways I know of that can circumvent this problem without updating core or third-party code logic:

1. (Recommended) Add a "Must Use" Plugin to your installation that adjusts the settings you need. MU Plugins load the earliest in the Wordpress lifecycle and will be able to give you the ability to override your plugins and your core without directly altering them. In my case, I set up a simple MU Plugin with the following logic:

// ep_pre_request_args is an ElasticPress-specific call that we need to adjust for all outbound HTTP requests
add_filter('ep_pre_request_args', function($args){
    if($_ENV['ELASTICSEARCH_SSL_PATH'] ?? false) {
        $args['sslcertificates'] = $_ENV['ELASTICSEARCH_SSL_PATH'];
    }
    return $args;
});

2. (Not Recommended) If you have absolutely no other options, you can also append your Root CA to wp-includes/certificates/ca-bundle.crt. This will seemingly "correct" the underlying issue and you will get proper verification of your SSL Certificates, but this method will fail each time you update Wordpress unless you bake in additional automation.

I'm adding this answer because I had thought that I was doing something wrong or wonky in my setup for days before I ever even bothered to delve deeper into the plugin source code. Hopefully this might save somebody some time if they're doing anything similar.

Christadelphian

Answer 29

Non of the answers mentioned that might be a role to connect to internal vpn i had this issue before and was asking to be on a private network

Mackenziemackerel

Answer 30

in my case while I am setting up SSl webserver using NodeJS the problem was because I did not attach the Bundle file certificate , finally I solved the problem by adding that file as following :

Note : code from aboutssl.org

var https = require('https');
var fs = require('fs');
var https_options = {
key: fs.readFileSync("/path/to/private.key"),
cert: fs.readFileSync("/path/to/your_domain_name.crt"),
ca: [
fs.readFileSync('path/to/CA_root.crt'),
fs.readFileSync('path/to/ca_bundle_certificate.crt') // this is the bundle file
]
};
https.createServer(options, function (req, res) {
res.writeHead(200);
res.end("Welcome to Node.js HTTPS Servern");
}).listen(8443)

In the above, replace the text in bold with the following.

path/to/private.key – This is your private key file’s path.

path/to/your_domain_name.crt – Enter your SSL certificate file’s path.

path/to/CA_root.crt – Provide the CA root certificate file’s full path.

path/to/ca_bundle_certificate – This is the full path of your uploaded CA bundle file.

reference: https://aboutssl.org/how-to-install-ssl-certificate-on-node-js/

Verditer

Answer 31

This can be caused by Homebrew, if you use it. In my case, the problem was caused by having a broken curl installed through brew as a dependency of some other package, which shadowed the perfectly functional curl provided by the OS.

Check where your curl is coming from with which curl. If it's from brew, you can then run brew unlink curl to "hide" the offending package.

Manzano

Answer 32

For me, the problem was the AVG Anti-virus "web-shield". Disabling the web-shield, combined with solutions given in other answers, fixed my problem.

Using the option --trace-ascii was helpful for debugging:

curl --trace-ascii - https://www.example.com

(using - in --trace-ascii - causes the trace to be printed to the std-out).

If AVG is causing problems, you'll see text similar to

0040: .U.../generated by AVG Antivirus for SSL/TLS scanning1.0...U....
0080: AVG Web/Mail Shield1!

Tetravalent

Answer 33

ULTIMATE SOLUTION FOR WAMP AND XAMP USERS FOR WINDOWS 8,10,11+

PART 1

1. Download https://curl.haxx.se/ca/cacert.pem

2. After download, move this file to your wamp server. For exp: C:\wamp64\bin\php\php8.2.0\extras\ssl

3. Search and uncomment the curl.cainfo in php.ini file located here (php folder) C:\wamp64\bin\php\php8.2.0

curl.cainfo="C:\wamp64\bin\php\php8.2.0\extras\ssl\cacert.pem"

PART 2

1. Search and uncomment the curl.cainfo in php.ini file located here (apache bin folder) C:\wamp64\bin\apache\apache2.4.54.2\bin

curl.cainfo="C:\wamp64\bin\php\php8.2.0\extras\ssl\cacert.pem"

Now restart your wamp server.

NOTE: change php version and apache version to yours

Elbrus

Answer 34

I had this problem with Digicert of all CAs. I created a digicertca.pem file that was just both intermediate and root pasted together into one file.

curl https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem
curl https://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt.pem

curl -v https://mydigisite.com/sign_on --cacert DigiCertCA.pem
...
*  subjectAltName: host "mydigisite.com" matched cert's "mydigisite.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
*  SSL certificate verify ok.
> GET /users/sign_in HTTP/1.1
> Host: mydigisite.com
> User-Agent: curl/7.65.1
> Accept: */*
...

Eorekan had the answer but only got myself and one other to up vote his answer.

Secor

Answer 35

Specifically for Windows users, using curl-7.57.0-win64-mingw or similar version.

This is a bit late, and the existing answers are correct. But I still had to struggle a bit to get it working on my Windows machine, though the process is actually pretty straight forward. So, sharing the step-by-step process.

This error basically means, curl is failing to verify the certificate of the target URI. If you trust the issuer of the certificate (CA), you can add that to the list of trusted certificates.

For that, browse the URI (e.g. on Chrome) and follow the steps

1. Right click on the secure padlock icon
2. Click on certificate, it'll open a window with the certificate details
3. Go to 'Certification Path' tab
4. Click the ROOT certificate
5. Click View Certificate, it'll open another certificate window
6. Go to Details tab
7. Click Copy to File, it'll open the export wizard
8. Click Next
9. Select 'Base-64 encoded X.509 (.CER)'
10. Click Next
11. Give a friendly name e.g. 'MyDomainX.cer' (browse to desired directory)
12. Click Next
13. Click Finish, it'll save the certificate file
14. Now open this .cer file and copy the contents (including -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----)
15. Now go to the directory where curl.exe is saved e.g. C:\SomeFolder\curl-7.57.0-win64-mingw\bin
16. Open the curl-ca-bundle.crt file with a text editor
17. Append the copied certificate text to the end of the file. Save

Now your command should execute fine in curl.

Dentoid

Some comment on the reason for downvote would be appreciated – Dentoid

I dont find any file named "curl-ca-bundle.crt" in "C:\xampp\apache\bin" (windows). Guess the down votes were due to this. I have my "curl.exe" in the "bin" folder mentioned above – Robillard

Answer 36

For my M1 Mac, I simply used this command and it worked:

/bin/bash -c "$(curl -fsSLk https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

What I did here is added a k in -fsSLk

Honeybunch

Don't post stuff that leads to have unsafe stuff installed when that is not even the question. – Haug

Answer 37

this can help you for guzzle :

$client = new Client(env('API_HOST'));
$client->setSslVerification(false);

tested on guzzle/guzzle 3.*

Shumate

Answer 38

Simple solution: IN ~/.sdkman/etc/config, change sdkman_insecure_ssl=true

Steps:
nano ~/.sdkman/etc/config
change sdkman_insecure_ssl=false to sdkman_insecure_ssl=true
save and exit

Tolley