curl : (60) SSL 인증서 : 로컬 발급자 인증서를 가져올 수 없습니다

curl : (60) SSL 인증서 : 로컬 발급자 인증서를 가져올 수 없습니다

---

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.

---

'SSL 인증서 문제 : 로컬 발급자 인증서를 가져올 수 없습니다'오류와 관련이 있습니다. 오히려 이것은 분명히 CURL 요청을 보내는 시스템에 적용됩니다 (요청을받는 서버는 없습니다)

1) https://curl.haxx.se/ca/cacert.pem 에서 최신 cacert.pem을 다운로드 하십시오.

2) php.ini에 다음 줄을 추가하십시오 (이것이 공유 호스팅이고 php.ini에 액세스 할 수없는 경우 public_html의 .user.ini에 추가 할 수 있습니다)

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

경로를 큰 따옴표로 묶어야합니다 !!!

3) 기본적으로 FastCGI 프로세스는 300 초마다 새 파일을 구문 분석합니다 (필요한 경우 https://ss88.uk/blog/fast-cgi-and-user-ini에서 제안한대로 몇 개의 파일을 추가하여 빈도를 변경할 수 있음) -파일 -the-new-htaccess / )

---

cURL이 서버에서 제공 한 인증서를 확인할 수 없으므로 실패합니다.

이 작업을 수행하는 데는 두 가지 옵션이 있습니다.

1. -kcurl이 안전하지 않은 연결을 할 수 있도록하는 cURL 옵션을 사용하십시오 . 즉 cURL은 인증서를 확인하지 않습니다.

2. 루트 CA (서버 인증서를 서명하는 CA)를 다음에 추가하십시오. etc/ssl/certs/ca-certificates.crt

보안 FTP 서버에 연결하려면 옵션 2를 사용해야합니다.

---

cURL 스크립트에 한 줄 코드를 추가 하여이 문제를 해결했습니다.

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

경고 : 요청이 절대적으로 안전하지 않습니다 (@YSU의 답변 참조)!

---

Git Extensions v3.48을 설치 한 후이 문제가 발생했습니다. mysysgit을 다시 설치하려고 시도했지만 동일한 문제가 발생했습니다. 마지막으로 다음을 사용하여 SSL 보안을 비활성화하십시오 (보안 관련 사항을 고려하십시오!).

git config --global http.sslVerify false

그러나 도메인 인증서가 있으면 (Win7)에 추가하는 것이 좋습니다.

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

---

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.

---

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.

---

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.

---

For me, simple install of certificates helped:

sudo apt-get install ca-certificates

---

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.google.com

---

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.

---

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)

---

On windows - if you run from cmd

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

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

Set environment variable:

CURL_CA_BUNDLE = C:\Program Files\curl-7.57.0\src\cacert.pem

and reload environment

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

---

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.

---

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.

---

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.

---

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.

---

this can help you for guzzle :

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

tested on guzzle/guzzle 3.*

---

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

참고URL : https://stackoverflow.com/questions/24611640/curl-60-ssl-certificate-unable-to-get-local-issuer-certificate