Project

General

Profile

Actions

New Content #14174

closed

Feedback on Certificate Management — Certificate Authority Management

Added by Jon Brown about 1 year ago. Updated 12 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Certificates
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Page: https://docs.netgate.com/pfsense/en/latest/certificates/ca.html

Feedback:

the Trust Store section should have this text added to it to clear it up.

Most users would not need to use this. Checking this when importing or creating a CA will do nothing for remote clients (like an OpenVPN client) that might need the CA cert later.

This allows a client application on the firewall to connect to something using that CA that would otherwise not be trusted. So for example a local LDAP server using LDAPS can be added to the firewall and be authenticated.
Actions #1

Updated by Jim Pingle about 1 year ago

  • Status changed from New to Rejected

The current text already covers the second point and the first point is irrelevant.

The text already says "When added to the trust store, a CA will be considered valid for all certificate operations performed by the operating system."

Nowhere is it implied it would have any effect on anything but the firewall OS itself.

Actions #2

Updated by Jon Brown about 1 year ago

see https://forum.netgate.com/topic/179007/add-this-certificate-authority-to-the-operating-system-trust-store/5?_=1679928736938

stephenw10 gave me a thumbs up on adding this to the docs. This is probably not for the network professional but the less experienced users for clarity. I certainly was unsure until i got this answer.

Actions #3

Updated by Sergei Shablovsky 12 months ago

Jon Brown wrote in #note-2:

see https://forum.netgate.com/topic/179007/add-this-certificate-authority-to-the-operating-system-trust-store/5?_=1679928736938

stephenw10 gave me a thumbs up on adding this to the docs. This is probably not for the network professional but the less experienced users for clarity. I certainly was unsure until i got this answer.

The threads like this is COSTANTLY appear on a forum & bugtracker here: and the answer are each time the ONE,- rejected.

In fact the Documentation need to be double manner: for NORMAL users (read “less experienced”, who even not clearly understand how DNS, DHCP, network mask and packets routing in TCP/IP working) with extension for EXPERIENCED SYSADMINS (who clearly understanding how IP stack working & packet routed in FreeBSD, and know all about networking and only need clarification how certain mechanisms realized in pfSense).

Now Documentation of pfSense are unpredictable MIX from very old info (may be from first versions), nowadays info (like DNSSEC, ipv6 tunneling, Cliudflare implementation, …) and some small quantity of examples.

So, Docs need to be much rewrited, but who agree to working on this?…

Actions

Also available in: Atom PDF