[SECURESIGN-1465] Enable customer provided cert for Fulcio

[fghanmi]

Changes in this PR:

• Accept user-provided certificate/private key (if not, generate automatically Fulcio root - as before)
• Allow the configuration of the Certificate attributes {organization_name, organization_email, common_name}

[bkabrda]

Thanks for the PR, I think this works really well, except some scenarios with cert/key changes that I think would not be covered right now. Specifically, in the certificates.yml file:

• The whole Create Fulcio root block is only ran if one of the files is missing on the managed node. We can no longer do this, as we have to expect the user to e.g. first let the role generate key automatically and then later provide their own cert or change the settings somehow (or rotate their provided cert etc). I think this will be tricky to handle but we have to do it and consider all scenarios when user changes from one way of doing something to another way.
• The same applies to the Create Fulcio public key task, which would now only run when the public key file doesn't exist (because of the creates).
• Same for Create self-signed Fulcio root from CSR.
• I think the Create certificate signing request (CSR) for Fulcio root certificate with your changes will run every time and generate a different cert, which is not what we want.

I know this is going to be tedious, but we have to switch from the "do these things" mindset here to "ensure the files are in the desired state". Let me know if you need any help.

[bkabrda]

Hi Firas, thanks for implementing the requested changes. I think this version is better, but there are still some scenarios that need to be covered - see the comments inline.

[bkabrda]

For the two private key tasks, I think we should:

• Use a different path for the key file for each task. For example, if the user first provided a key themselves but later wanted to switch to a role-generated key, we would just happily keep using their provided old key. Using different paths for the file should solve this.
• For the user-provided key, I think if it's not provided we should explicitly ensure that the file is absent (we don't want users credentials laying around on the node unnecessarily).
• Based on what the user configured, we can then copy either the role generated key or the user key to tas_single_node_remote_fulcio_private_key as the final destination (so we won't have to change any tasks that depend on that file location).

[bkabrda]

• Will this command work even if user provides an RSA key?
• For RSA keys, generating the public key can yield a different output every time. I think what we should do is we should have a task that finds out whether the public key corresponds to the private key; if not, then this task should regenerate.

[bkabrda]

Similar to one of the previous comments - if user first provided cert on their own and then they wanted to switch to role-generated cert, this wouldn't properly regenerate. I think the last line of the conditon should be replaced by checking a result of a new task which will verify whether the existing private/public key match the existing cert.

[bkabrda]

Thanks for putting all the work into this, it looks much better now. I left couple comments inline, but they're mostly minor at this point (still need to be addressed though).

[bkabrda]

We now have the nested values under tas_single_node_fulcio, so we can remove these ones, right?

[bkabrda]

Let's mention that this is mutually exclusive with certificate (it is, right?)

[bkabrda]

I don't think we need to do these 2 stats calls. We can use the user-provided key when tas_single_node_remote_fulcio_user_provided_private_key is defined and non-empty, otherwise use the auto-generated key. Does that make sense?

[bkabrda]

Will this work if the private key is RSA?

[fghanmi]

Yes, it works

# cat private_key.pem 
-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDcRXm+Y2Er3aA3
....
sXlWPzGfjMAx4DPX5NhXFLTR7R051CkKXgSOmxC2sJ1bhiMAySYo00RH0ap0TxWe
Mo44kmQXlw0aWC4C1TaEJyz2Yw==
-----END PRIVATE KEY-----
# openssl rsa -in private_key.pem -pubout -out public_key.pem
writing RSA key
# openssl ec -pubout -in private_key.pem -passin 'pass:rhtas'  | openssl md5 | awk '{print $NF}' &&  openssl md5 public | awk '{print $NF}' 
read EC key
writing EC key
4de214eff3b63c39c3a248a7e01f8c22
4de214eff3b63c39c3a248a7e01f8c22