system/trust: Read certificates from filesystem

[Monviech]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

Some plugins store ACME certificates on disk, e.g. OPNWAF (Apache) or Caddy.

It would be nice if these certificates could be displayed inside "Trust: Certificates" and emitted via API so they can be consumed via the Certificates Dashboard widget.

Describe the solution you like

• Including the information that the plugin has ACME Certificates in the filesystem, e.g. by using plugins.inc to emit:

  • The paths (multiple paths possible) the certificates are stored in (so they can be recursively read by a script)
  • Name of the Application (e.g. OPNWAF/ Caddy / ACME etc...)
  • Maybe which files or folder names to skip (e.g. files ending with *.key or a folder named *custom) during recursion.

• A script reads the certificates from disk and together with the information from plugins.inc, displays them in "Trust: Certificates"

  • Command buttons that can edit/delete/clone the certificates should not be available
  • Certificates should be marked as automatic, and the plugin they came from
  • These certificates should not be selectable in certificate field types
  • The certificates should not be imported into the trust store, just displayed in the existing bootgrid
  • (Maybe) They could be downloadable, and information displayed when the commands are executed, though this would also include the need of private key parsing etc... might make the scope too big.

• The Certificate API should emit these certificates in the same manner as the existing ones, so they can be consumed by the Certificates Widget and the Certificate GUI pages.

[AdSchellevis]

Notes to self:

• In order to collect certificates, we need to funnel the action through configd as usually we're not able to access them via an ordinary user (e.g. opnwaf uses /usr/local/md/domains)
• Static children should be registered in CertificatesField using a construct similar to

  core/src/opnsense/mvc/app/models/OPNsense/IPsec/FieldTypes/VTIField.php

  Line 42 in 769fa74

  protected static function getStaticChildren()

• Payload handling should (partially) be moved inside it's own private method so both static as config items can use something. similar:

  core/src/opnsense/mvc/app/models/OPNsense/Trust/FieldTypes/CertificatesField.php

  Lines 120 to 142 in 769fa74

  	$payload = false;
  	if (!empty((string)$node->crt)) {
  	$payload = \OPNsense\Trust\Store::parseX509($node->crt_payload);
  	} elseif (!empty((string)$node->csr)) {
  	$payload = \OPNsense\Trust\Store::parseCSR($node->csr_payload);
  	}
  	if ($payload !== false) {
  	foreach ($payload as $key => $value) {
  	if (isset($node->$key)) {
  	/* prevent injection of invalid countries which trip migrations */
  	if ($key == 'country') {
  	if (empty($countries)) {
  	$countries = array_keys($node->$key->getNodeData());
  	}
  	if (in_array($value, $countries)) {
  	$node->$key = $value;
  	}
  	} else {
  	$node->$key = $value;
  	}
  	}
  	}
  	}

• We likely want to cache the static results to prevent excessive configd access