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         


        

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.