As I responded here, I prefer to add a --template flag to step ca init instead of signing the CSR as it is.

Regarding step ca renew-ca with a better name, I don't see that coming to the step ca command at any point soon because the CA would need the root key, and it is something that it does not have. At the same time some users, especially the ones using HSM do "ceremonies" for signing root or intermediate keys.

For this part, the first half of the problem is getting the necessary csr from step ca init. It is more intuitive to add it there, so that the user does not need to know 2 ways that they can start their own step-ca server. Plus this one also configures ca.json. How the signing is done to be an appropriate intermediate it's up to the user.

Creating the csr would be useful if the user does not have direct access to the root certificate keys and the root might not use the same engine. Like in my school/lab example, no lab has access to the school's root, but they can send csr to it to be signed at some point.

CA would need the root key

I am confused. Why does the CA need the root key? The current usage of --root --key only copies the root crt, but not the the key as far as I can see. step ca renew-ca would basically fill that missing step when the root key is not present, i.e. either make a csr request or copy a signed certificate bundle into production. Freeipa for example does exactly those steps for using an external ca

Like in my school/lab example, no lab has access to the school's root, but they can send csr to it to be signed at some point.

For your school/lab example, a way to pass to step ca init a specific intermediate and key would be more useful. Right now, you can do that by replacing files.

I am confused. Why does the CA need the root key?

I understand that you wanted a command that will do an HTTP request to the CA to renew the intermediate. We can consider creating an endpoint that creates a CSR for the intermediate, but in that case, it won't renew the key, it gets way more complicated if you want to do that.

Pushing the signed intermediate might be more complicated, as it will require overwriting files, where permissions might be a problem, and that is without considering the authentication or a change in a configmap in k8s. I think for this, it makes more sense to use some mechanism to replace the file/configmap itself and HUP the server to reload the configuration.

I understand that you wanted a command that will do an HTTP request to the CA to renew the intermediate.

There's a misunderstanding here. The flag would be in step ca init which runs offline. The idea is to use the same flags and prompts to generate the ca certificate, but have a csr generated to be later signed. And copied in.

Indeed we can simply copy the intermediate certificate, but it would be nice to have pre-checks, like is the intermediate signed by the root we want, is the time valid, etc.

I think for this, it makes more sense to use some mechanism to replace the file/configmap itself and HUP the server to reload the configuration.

👍 Just for clarity that would mean creating intermediate2.crt and changing the json to point to that right?

There's a misunderstanding here. The flag would be in step ca init which runs offline. The idea is to use the same flags and prompts to generate the ca certificate, but have a csr generated to be later signed. And copied in.

Yes, there was a misunderstanding. And now the --csr flag makes more sense to me, so instead of creating a fully valid environment, it creates the same or a very similar ca.json, but writing a CSR on disk instead of a certificate. You take that CSR, you sign it somehow, and write it in the path present in the ca.json, or by your suggestion, that I misunderstood, using a command that edits the ca.json and verifies the signed intermediate is a valid one.

👍 Just for clarity that would mean creating intermediate2.crt and changing the json to point to that right?

Yes, but I meant to use some script outside of the scope of step-ca.