PKI: Imported Issuer Clarity

[dannyleesmith]

Is your feature request related to a problem? Please describe. I am working on a project to automate CA rotation in PKI mounts. When using the pki/intermediate/set-signed endpoint the response generally looks like this:

{
  "request_id": "235a392a-6aab-6ced-3c6e-ab0fb7dca760",
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
    "existing_issuers": [
      "27dd1484-7695-a508-9bf5-0c44ef5037a0",
      "1fbb3cd9-122c-c775-4b9f-6687c67eb039"
    ],
    "existing_keys": null,
    "imported_issuers": [
      "a44facfa-5fd5-fd1f-5ac7-79348ef61ee4"
    ],
    "imported_keys": null,
    "mapping": {
      "1fbb3cd9-122c-c775-4b9f-6687c67eb039": "",
      "27dd1484-7695-a508-9bf5-0c44ef5037a0": "",
      "a44facfa-5fd5-fd1f-5ac7-79348ef61ee4": "9a5e7782-18f5-20ca-41fe-7469e062a602"
    }
  },
  "warnings": null
}

This output was for a newly signed certificate for an intermediate where the chain has not changed.

It is frustrating that of all the issuers returned (imported_issuers in this case was 1 in this case but would be more if it were the first time parent CA(s) were being imported) there is not a field to specify the one that is for the new intermediate. This is important because it is the one you might want to feed through to following commands to perform actions such as updating it to have a friendly name, make it the default issuer for a role, make it the default issuer for the mount, etc.

Describe the solution you'd like What would be ideal is that set-signed could determine the issuer reference of all the returned issuers so it could be fed through to the following commands. Alternatively, if there is some sort of consistency to the returned values (for example if imported_issuers or mapping can also be determined based on the input then this could be calculated.

For example, in testing it seems that the mapping field has the keys returned in the order that a bundle was imported. For example, if I had a root, 2nd tier intermediate, and third tier intermediate, and I specifically built the PEM bundle to be in that order, the final key was the correct reference. If this is the case then a documentation update to make this clear that the order is always consistent would allow for those writing automation to ensure they have a consistent approach to building chains. Particularly if they only needed to ensure the final certificate was the new certificate that had just been signed.

Describe alternatives you've considered An alternative was to take a read of all the existing keys before performing set-signed and then comparing that to a list after the fact. This worked most of the time but did not feel as consistent.

Explain any additional use-cases The use cases above I feel cover the problem well.

Additional context No other context comes to mind but happy to field questions and provide what I can.

[stevendpclark]

Hi @dannyleesmith,

Agreed, when importing multiple CAs through set-signed the response isn't the most helpful. Also the ordering within mapping field should not be relied upon, there are quite a few layers of code that might in the future tweak the output of that map.

A few questions to start a discussion around this:

• Is there a reason multiple set-signed calls with a single CA for each isn't workable solution? That would guarantee the id back with the current api.
• There isn't any sort of guarantee that the pem input field isn't importing many different intermediates, what would you expect to be returned if we imported multiple intermediate CAs that weren't related?
• If we accepted another input field, a slice of maps, that could be used as a "reference" field which was returned back with the imported id in a new field would that be satisfactory? Perhaps this new field could also set the values of issuer_name as an example upon import to avoid the need to update later on?

[dannyleesmith]

Hi @stevendpclark,

Yes I had found the mapping field to be unreliable so went through additional testing and that then led me to an answer that speaks to your first question.

• set-signed multiple times:
  • I have produced a runbook using both CLI and API commands, and now a Python script (with a view of automating CA rotation) that does exactly this
  • I found that the ca_chain returned by pki/root/sign-intermediate appears to be consistently in the same order
  • In a three tier architecture (external root CA, intermediate CA in Vault root namespace to sign other intermediates, intermediate CA in namespaces used for certificate issuance) this has consistently provided a chain in the order of:
    1. newly signed certificate
    2. root namespace intermediate CA certificate
    3. external root CA certificate
  • I then do a set-signed for the first cert in the array/list, then a set-signed for the remainder (which also means it would handle a chain of differing length); this has been working well so I am not blocked by this and have a valid workaround
• pem input guarantees:
  • very true
  • I think in my head, naively perhaps, I assumed that because the CN given in the CSR step is visible on the issuer of the imported signed certificate (in the UI anyway) that somehow it would "know" this was an issuer I cared about
• new field: sounds interesting, I think that would certainly be useful in some situations if you can be clear on the inputs and clear on the outputs

Thanks for looking into this one.