Regression #14876: ``ca_setup_trust_store()`` behavior conflicts with ``certctl`` - pfSense - pfSense bugtracker

Actions

Copy link

Regression #14876

closed

``ca_setup_trust_store()`` behavior conflicts with ``certctl``

Added by Lev Prokofev about 1 year ago. Updated about 1 year ago.

Status:

Resolved

Priority:

Normal

Assignee:

Jim Pingle

Category:

Certificates

Target version:

2.7.1

Start date:

Due date:

% Done:

100%

Estimated time:

Plus Target Version:

23.09

Release Notes:

Force Exclusion

Affected Version:

Affected Architecture:

Description

When you add a commit ID, it generates a proper link, for example, id 01d6aeb62f876fc9b6f9e1083e7586b1866c725b

but the package fails to fetch the content.

Package version 2.2.6

tested on

23.09-BETA (amd64)
built on Fri Oct 13 6:00:00 UTC 2023
FreeBSD 14.0-CURRENT

Files

Download all files

clipboard-202310141030-jlrrh.png (44.2 KB) clipboard-202310141030-jlrrh.png		Lev Prokofev, 10/14/2023 06:30 AM
clipboard-202310141031-33dhy.png (35.9 KB) clipboard-202310141031-33dhy.png		Lev Prokofev, 10/14/2023 06:31 AM

Actions

Copy link

Updated by Danilo Zrenjanin about 1 year ago

Status changed from New to Confirmed

I can confirm this behavior.

23.09-BETA (amd64)
built on Fri Oct 13 6:00:00 UTC 2023
FreeBSD 14.0-CURRENT

Actions

Copy link

Updated by Christopher Cope about 1 year ago

It looks to be related to SSL, disabling curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); in the download_file function allows it to fetch successfully.

Since there aren't any CA certificates at /etc/ssl/certs/, in the beta or 23.05.1, this seems to be an issue with the ones specified at build.

This would most likely affect more than just the system patches.

Actions

Copy link

Updated by Jim Pingle about 1 year ago

Project changed from pfSense Packages to pfSense
Subject changed from System_Patches fails to fetch a commit content. to ``ca_setup_trust_store()`` behavior conflicts with ``certctl``
Category changed from System Patches to Certificates
Assignee set to Jim Pingle
Target version set to 2.8.0
Plus Target Version set to 23.09
Release Notes set to Default

This is really a base system issue and likely the same root cause as other issues we've seen.

certctl rehash is writing its list of trusted certificates to /etc/ssl/certs which is also where the certificate manager writes its trusted CA certificates in ca_setup_trust_store(). The problem is that ca_setup_trust_store() removes all of the *.0 files from that directory before writing its own.

The quickest fix is to have that function re-run certctl rehash after it's done, but that may not be the best long-term fix. Ideally we should be writing our own CA certs elsewhere also also feeding them through certctl, though a quick attempt at using a custom directory for that didn't appear to work properly for whatever reason.

We may want to go the quick route for now and work on a better fix for the next release.

Actions

Copy link