Importing external certificates/certificates authorities in V2

[Coffee-Processing-Unit]

Describe the bug

1. In V1, when creating a certificate authority, there is a field called 'method' to specify a creation method - import or internal, as internal generates new crt and prv fields. When the method is 'import', a 'prv' field is not needed, and pfSense can use CA without specifying their private key.
   In Certificate Authority creation #519 , you created an option to generate values for the 'crt' and 'key' fields in V2.
   The functionality of importing external certificate authority without the 'prv' field is still missing in V2.
2. In addition, when importing an external certificate, using the 'crt' and 'prv' fields, the certificate appears to be created without an association to a CA object already existing in pfSense, even though it is issued by it.
   An interesting phenomenon is that when clicking 'edit' in the web configurator on the certificate object created with V2, making no changes, and clicking 'save', the pfSense suddenly recognizes the existing CA object as the issuer of this certificate.
   Can it be related to the way the certificates are sent to the API? In V1 they were sent in base64 format, in V1 they were sent in plain text. Can you explain the difference?
   I will stress that I'm sending the same request to /api/v1/system/certificate, with the 'crt' and 'prv' in base64, and with the 'import' method, and the certificate was created successfully and are shown as issued by the CA object.

To Reproduce

1. send POST request to /api/v2/system/certificate_authority. The 'prv' field is mandatory.
2. send a POST request to /api/v2/system/certificate.
   specify the 'crt' and 'prv' fields using plain text X509 certificate.
   the certificate is being created, but not appears to be signed by the existing CA object.

• Package Version V1 - v1.7.6
• Package Version V2 - v2.2.2

[Coffee-Processing-Unit]

@jaredhendrickson13 hey, can you please give a short update on the subject? Thank you!

[jaredhendrickson13]

Thanks for reporting these. Apologies for missing this issue earlier, I must have overlooked this one.

1. In v2, the various methods are broken up into their own endpoints instead of fitting them all into a single endpoint. This was done to reduce the amount of variability in the schema for that endpoint. I can relax the validation for /api/v2/system/certificate_authority's (which is the v2 equivalent of the import method in v1) prv field in v2.3.0. You're correct that it should not require the prv field.
2. I'm assuming the API is missing a pfSense function call that is normally performed by the webConfigurator. I'll do some digging and see what's missing to relink the certificates. I should be able to have a fix for that in v2.3.0 as well. The base64 encoding/decoding is handled by the API's representation system in v2, so the client does not need to handle that like they did in v1. In both v1 and v2 the values will be written to config in base64 as pfSense expects so it's unlikely to be the of cause this issue.

[jaredhendrickson13]

2. I'm assuming the API is missing a pfSense function call that is normally performed by the webConfigurator. I'll do some digging and see what's missing to relink the certificates. I should be able to have a fix for that in v2.3.0 as well. The base64 encoding/decoding is handled by the API's representation system in v2, so the client does not need to handle that like they did in v1. In both v1 and v2 the values will be written to config in base64 as pfSense expects so it's unlikely to be the of cause this issue.

There were two issues. Firstly, v2 did not have the caref field defined in its schema so it was unable to handle certificates with a linked CA. Secondly, relinking is handled by pfSense's cert_import function which was not being called during Certificate creations (imports). These fixes will be in the next release which should be sometime this week.

[Coffee-Processing-Unit]

Thank you very much!
Just to be certain about 2 - the schema will be the same as v1, current? The caref field won't be provided manually in the request but will be mapped automatically if a matching CA object exists.

[jaredhendrickson13]

Correct, the caref will be automatically determined and assigned by pfSense upon import if there is a matching CA. It is not manually assigned in the request by the client.