Project

General

Profile

Actions

Regression #14876

closed
LP JP

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

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

Added by Lev Prokofev almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Certificates
Target version:
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

DZ Updated by Danilo Zrenjanin almost 3 years ago Actions #1

  • 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

CC Updated by Christopher Cope almost 3 years ago Actions #2

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.

JP Updated by Jim Pingle almost 3 years ago Actions #3

  • 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.

JP Updated by Jim Pingle almost 3 years ago Actions #4

  • Release Notes changed from Default to Force Exclusion

JP Updated by Jim Pingle almost 3 years ago Actions #5

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

Applied in changeset commit:72c441e9e0c0f3d4cd26f554a67aa91e06734b5b.

DZ Updated by Danilo Zrenjanin almost 3 years ago Actions #6

It works fine on:

23.09.b.20231018.0600

I am marking this ticket as resolved.

JP Updated by Jim Pingle almost 3 years ago Actions #7

  • Status changed from Feedback to Resolved

JP Updated by Jim Pingle almost 3 years ago Actions #8

  • Target version changed from 2.8.0 to 2.7.1
Actions

Also available in: Atom