You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)
Issue details
We are currently running and configuring step-ca from infra-structure-as code. We want to add a webhook to a provisioner in the configurationfile ca.json.
Currently the entire webhook configuration is read from ca.json EXCEPT the secret that is used to sign the http-requests. The request will get signed by an empty secret if you configure the webhook in ca.json.
Make sure the secret is also read from ca.json.
To protect it and not store it plaintext/base64 encoded, it might be possible to encrypt the secret with the public key of the intermediate CA. Since the CA has the private key for its normal operations, it can decrypt the secret from the configfile.
Why is this needed?
To be to manage the configuration of the CA without having to run step cli-commands.
This allows for automating the configuration in a predictable way.
The text was updated successfully, but these errors were encountered:
Yes, we wanted to discourage keeping secrets in ca.json. Encrypting with the pub key of the intermediate is an interesting idea, but there may be risks that arise when using that keypair for more than just certificate signing. You can configure the webhook server to request and verify a client certificate if you want to be sure the request is coming from step-ca without using a secret.
Hello!
Issue details
We are currently running and configuring step-ca from infra-structure-as code. We want to add a webhook to a provisioner in the configurationfile ca.json.
Currently the entire webhook configuration is read from ca.json EXCEPT the secret that is used to sign the http-requests. The request will get signed by an empty secret if you configure the webhook in ca.json.
Make sure the secret is also read from ca.json.
To protect it and not store it plaintext/base64 encoded, it might be possible to encrypt the secret with the public key of the intermediate CA. Since the CA has the private key for its normal operations, it can decrypt the secret from the configfile.
Why is this needed?
To be to manage the configuration of the CA without having to run
step
cli-commands.This allows for automating the configuration in a predictable way.
The text was updated successfully, but these errors were encountered: