E network curl error problem with the ssl ca cert path access rights

Are you facing a curl error 77 problem with the SSL CA cert while curling an SSL website?

One of the main reasons for this error is broken or missing SSL chain certificate files on the server.

At Bobcares, we help our customers to fix similar SSL errors as part of our Server Management Services.

Today, let’s discuss the details on how to fix this error.

What is curl error 77 problem with the SSL CA cert?

Curl error 77 error is a server-side error.  This error indicated that the chain certificate files are missing or “broken”. Usually, this error happens simply by outdated SSL certificate(s) for cURL installed on the server.  Also, the wrong or incomplete configuration settings on the server can trigger the error on the website.

The error looks like,

Frequently, some website’s PHP scripts may fail with curl error 77 in Plesk servers.  Then the website shows the following error:

cURL error (77): Problem with the SSL CA cert (path? access rights?)cURL error (77): Problem with the SSL CA cert (path? access rights?)

This error occurs when PHP cURL uses an outdated set of root certificates to verify server certificates.

How to fix curl error 77 problem with the SSL CA cert

Now, let’s see how our Support Engineers fix the curl error 77  for our customers.

Curling an SSL website can result in an error curl: (77) Problem with the SSL CA cert (path? access rights?)on certain servers.

This error is the result of  SSL chain certificate files in the PKI directory being corrupted or missed.

Therefore, we make sure the files /etc/pki/tls/certs/ca-bundle.crt and /etc/pki/tls/certs/ca-bundle.trust.crt exist on the server. If they do not exist, we set up them for our customers.

Sometimes, the error gets resolve by removing and reinstalling the ca certificate.

In a CentOS server, we use the below commands to remove ca-bundle and to install a ca-certificate.

rm -f /etc/ssl/certs/ca-bundle.crt

yum reinstall -y ca-certificates

In Plesk servers, adding the following code to %plesk_dir%adminconfpanel.ini solve the error. By default,

%plesk_dir% is C:Program Files (x86)Plesk

[php]
curlCertificatesUrl="http://curl.haxx.se/ca/cacert.pem

Insufficient user permission

Sometimes the curl requests to https:// addresses stop working for cPanel users. However, the root user can still run the curl -I -v https://google.comcommand without any issue.​ 

The problem is due to insufficient permission of the user.  The user who is trying to accesscurl -I -v https://google.com doesn’t have enough permission to access /etc/pki directory. This due to the user only has jailed ssh access.

So, our Support Engineers fix the error by granting full access to the user.

Other common SSL certificate problem

Similarly, the error SSL certificate problem: Unable to get local issuer certificate can occur when a self-signed certificate cannot be verified or it shows that the root certificates on the system are not working correctly.

Also, It is important to note that this applies to the system sending the CURL request, and NOT the server receiving the request.

To fix the error,

1. Initially, download cacert.pem. from https://curl.haxx.se/ca/cacert.pem

2. Add the following line to php.ini:

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

Furthermore, if the server is shared hosting, add the above value to .user.ini file in the public_html folder.

3. Restart PHP

Now, CURL is able to read HTTPS URL without any error.

[Need assistance to fix curl error 77?- We’re available 24/7.]

Conclusion

In short, the curl error 77 problem with the SSL CA cert occurs when SSL chain certificate files are missing or broken. Today, we saw how our Support Engineers fixed this error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Skip to content

When trying to curl or git clone something over HTTPS as a regular user, it fails with the error:

fatal: unable to access 'https://github.com/mikemackintosh/xxx/': Problem with the SSL CA cert (path? access rights?)

Note: If i run the commands as root, it works fine, but root should not be the only user able to communicate over ssl.

So I think to myself, ok, what’s curl doing behind the scenes:

$ GIT_CURL_VERBOSE=1 git clone https://github.com/mikemackintosh/xxx
Cloning into 'xxx'...
* Couldn't find host github.com in the .netrc file; using defaults
* Hostname was NOT found in DNS cache
*   Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* error reading ca cert file /etc/ssl/certs/ca-certificates.crt (Error while reading file.)
* Closing connection 0
fatal: unable to access 'https://github.com/mikemackintosh/xxx/': Problem with the SSL CA cert (path? access rights?)

As a result, we are able to confirm the ca-certificate file is: /etc/ssl/certs/ca-certificates.crt which matches curl-config -ca output.

The next step is to try and read the file. As just a plain-old, non-root user:

$ cat /etc/ssl/certs/ca-certificates.crt
cat: /etc/ssl/certs/ca-certificates.crt: Permission denied

Now that seems strange.

$ sudo ls -la /etc/ssl/certs/ca-certificates.crt
-rw-r--r-- 1 root root 273790 Jun 15 22:35 /etc/ssl/certs/ca-certificates.crt

$ sudo lsattr /etc/ssl/certs/ca-certificates.crt
-------------e-- /etc/ssl/certs/ca-certificates.crt

So looking at the permissions, it is world-readable. There should be no problem accessing it. No crazy attributes preventing access.

doing an ls -la /etc/ssl/certs/ returns:

...
l????????? ? ? ? ?            ? Verisign_Class_4_Public_Primary_Certification_Authority_-_G3.pem
l????????? ? ? ? ?            ? VeriSign_Universal_Root_Certification_Authority.pem
l????????? ? ? ? ?            ? Visa_eCommerce_Root.pem
l????????? ? ? ? ?            ? WellsSecure_Public_Root_Certificate_Authority.pem
l????????? ? ? ? ?            ? WoSign_China.pem
l????????? ? ? ? ?            ? WoSign.pem
...

If I run a sudo cat /etc/ssl/certs/ca-certificates.pem, it spits out the contents as expected.

Oh, this is for sure a permissions issue.

Doing some googling, i’ve found that there is an ssl-cert group, but this group does not have rights to the /etc/ssl/certs directory.

Ruled out apparmor, ruled out disk corruption, there is no improvement if I run update-ca-certificates (w/wo -f), etc.

Has anyone seen this behavior?

I have never seen anything like this before, but I have duplicated it on two separate machines. As a note, I do come from a CentOS/RHEL background, so this could be a normal behavior of Ubuntu, but i’d love to find out a real solution.