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.
