Feature request: Define per provisioner intermediate certificate and key

[COD3HUNT3R]

Currently we can use a single cert and key for intermediate certificate and that is defined in the root section of the config.

{
  "root": "examples/pki/secrets/root_ca.crt",
  "federatedRoots": ["examples/pki/secrets/federated_root_ca.crt"],
  "crt": "examples/pki/secrets/intermediate_ca.crt",
  "key": "examples/pki/secrets/intermediate_ca_key",
  ....
  "authority": {
    "provisioners": [
      {
        "type": "ACME",
        "name": "my-acme-provisioner"
      }
    ]
  ....
  }
}

What we want to achieve is per provisioner different intermediate cert and key like below. Is it possible?

"authority": {
    "provisioners": [
      {
        "type": "ACME",
        "name": "my-acme-provisioner-1",
        "crt": "examples/pki/secrets/intermediate_ca-1.crt",
        "key": "examples/pki/secrets/intermediate_ca_key-1"
      },
       {
        "type": "ACME",
        "name": "my-acme-provisioner-2",
        "crt": "examples/pki/secrets/intermediate_ca-2.crt",
        "key": "examples/pki/secrets/intermediate_ca_key-2"
      },
    ]

[hslatman]

Hi @COD3HUNT3R, this is not possible withstep-ca today. It assumes there's a single signing chain, and changing that to support multiple signing chains would be quite involved if done in a non-hacky way.

If you really need multiple signing chains, you'll need to run multiple instances of step-ca. While there's some overhead in doing so (multiple processes, more processes to manage), it's not too bad in practice if you use the --context flag when performing operations against the CAs.

[COD3HUNT3R]

I can use Nginx to map paths for acme directory. I am keeping this issue open if anyone wants to implement this. Feel free to close if this out of scope.

[flixman]

@hslatman Sorry for jumping in: Does this mean that if I want to generate the delegated CAs for a k8s cluster, I should generate them signed by the intermediate CA (for which I have the corresponding SANs in place)?

[hslatman]

@hslatman Sorry for jumping in: Does this mean that if I want to generate the delegated CAs for a k8s cluster, I should generate them signed by the intermediate CA (for which I have the corresponding SANs in place)?

That can work, if your current intermediate CA has a path length that allows for another intermediate to be part of the chain (i.e. path length > 0). If you're currently using a step generated root and intermediate (using the defaults), that won't be the case. If you still want the same root, the subordinate CA would have to be a new intermediate signed by the root in that case. If you created a custom root and intermediate, then it's possible the path length allows for the longer chain.

[flixman]

@hslatman Indeed! Seems to work. Thank you!