curl unable to connect via TLS after change to default trust store?

Wapcaplet

Wapcaplet

After the recent change to ftp/curl where security/ca_root_nss was removed as a dependency in favor of using the base system's default trust store, I can't connect via TLS after removing security/ca_root_nss from my system.

Code: 
$ curl -I https://google.com
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Reinstalling security/ca_root_nss fixes the problem. I rarely use curl by itself, but whenever I update my ports tree or system source using git over https:// (which uses curl for the secure connection), it gives the same error.

This is on FreeBSD 13.2-RELEASE-p4 amd64, with packages built locally using ports-mgmt/poudriere and OpenSSL 1.1.1 from ports.

Can anyone else confirm this behavior?
 
SirDice said:
This may have had something to do with it: https://cgit.freebsd.org/ports/comm...e?id=52e0c40367d3ebd09ab7169e025c37fbf70b8dee

I noticed a disappearance and reappearance of /usr/local/etc/ssl/cert.pem, actually the whole /usr/local/etc/ssl/ directory. Which caused some problems with Rails too.
Click to expand...
/usr/local/etc/ssl/ still exists on my system after deleting security/ca_root_nss, though obvously cert.pem isn't there.

My issue is that curl (and git) should connect over TLS without requiring security/ca_root_nss because of this commit: https://cgit.freebsd.org/ports/commit/?id=4881eceec92a58dae0979a2744fe71fca8675cf9

That's not happening for me, and I can't figure out why.
 
It seems I ran into a related problem when I updated pkg from 1.19.2 to 1.20.7 (or .8) within some jails on a 12.4-RELEASE host.
pkg switched from fetch to curl, which insists on certificates being in the non-existent /etc/ssl/certs/ path instead of using /usr/share/certs/trusted/, to which the contents of /etc/ssl/certs (if present) are linked anyways...

However, reinstalling security/ca_root_nss *doesn't* solve the missing path/symlink.

I feel like manually adding that symlink to all ~20 jals on 2 12.4-RELEASE hosts is the wrong approach. I checked some random jails on a few 13.2-RELEASE hosts and here the path is (still?) there, so I hope I'm fine there...
 
I had this error, but if I run the same curl command as root user, I did not see the error.

I think it comes down to how I install updates (my umask), as I've had similar issues, so I went hunting:

Check that your /etc/ssl directory is readable by that user: you may need to chmod 755 /etc/ssl
 
gedge said:
I had this error, but if I run the same curl command as root user, I did not see the error.

I think it comes down to how I install updates (my umask), as I've had similar issues, so I went hunting:

Check that your /etc/ssl directory is readable by that user: you may need to chmod 755 /etc/ssl
Click to expand...

certctl rehash fixed it in all affected jails. The symlinks that this creates were also missing in the basejail templates. No idea why, but as those 12.4-RELEASE hosts and jails are soon to be upgraded anyways, I didn't dug any deeper into this...
 
You must log in or register to reply here.
Back
Top