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

fatal: unable to access ' 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
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 ' 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.

3

4 Answers

Run namei -mo /etc/ssl/certs/ca-certificates.crt. Match its output to the following:

f: /etc/ssl/certs/ca-certificates.crt drwxr-xr-x root root / drwxr-xr-x root root etc drwxr-xr-x root root ssl drwxr-xr-x root root certs -rw-r--r-- root root ca-certificates.crt

You can use chmod and chown to get everything back to the correct settings:

• sudo chown root / && chown root /etc/ && chown root /etc/ssl/ && chown root /etc/ssl/certs/ && chown root /etc/ssl/certs/ca-certificates.crt
• sudo chmod 755 /
• sudo chmod 755 /etc/
• sudo chmod 755 /etc/ssl/
• sudo chmod 755 /etc/ssl/certs
• sudo chmod 644 /etc/ssl/certs/ca-certificates.crt

I encountered the same issue today. Here is what I did:

GIT_CURL_VERBOSE=1 git clone

This clones repository in curl verbose mode (curl is causing issue right now)

Here is what I got

Cloning into 'oh-my-zsh'...
* Couldn't find host github.com in the .netrc file; using defaults
* Hostname was NOT found in DNS cache
* Trying 192.30.252.131...
* Connected to github.com (192.30.252.131) port 443 (#0)
* error reading ca cert file /bin/curl-ca-bundle.crt (Error while reading file.)
* Closing connection 0
fatal: unable to access ' Problem with the SSL CA cert (path? access rights?)

Note the line:

• error reading ca cert file /bin/curl-ca-bundle.crt (Error while reading file.)

I had a configuration issue in ~/.gitconfig [HTTP]->sslCAinfo section. You might not have the same issue, but it will give you enough information to debug on your own.

1

In unix, the whole path is checked, so in my opinion, you should check if the folders in the path have permissions, I think, they should have at least rw-, don't panic, w doesn't mean write if talking about folders... Because if you have /a/b/c/certificate.pem and you can't get past "b", you can't get past b :D

Hope it helps :)

2

Make sure you've CA certificates to allow SSL-based applications to check for the authenticity of SSL connections. They can be installed by:

sudo apt-get install ca-certificates openssl

This can be missing especially in Docker or CI containers.

If you have it, consider reinstalling it.

You can also try running: sudo update-ca-certificates.

Related:

• cURL not working (Error #77) for SSL connections
• curl: (77) pbm with the SSL CA cert (path? access rights?)

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy