JWK encrypted key / password options?

[haraldkubota]

Hi, this might be a lack of knowledge on my side, so if that's the case, just point me to the docs.

Running a CA (via step-ca) is great and it makes sense to encrypt the secret key with a password/passphrase.
Using the same password/passphrase when requesting a new certificate (via step cli) nags me a bit though: typing it is bad enough, but storing it unencrypted on clients seems to be wrong.
So wrong in fact that I am quite sure I miss something, but what is it?

How can I avoid using the CA key secret on all clients?

[maraino]

Hi @haraldkubota,

On step ca init you can use --password-file to set the password for encrypting the root and intermediate key, and --provisioner-password-file to encrypt the default provisioner.

You can also create a new provisioner using step ca provisioner add ... and remove the other one, either manually or with step ca provisioner remove ...

[mmalone]

Yea, there's tons of flexibility around this.

You can also change the password for your CA. The password is actually only used to decrypt the intermediate private key. So if you run step certificate change-pass $(step path)/secrets/intermediate_ca_key on your CA you can change that password. The root signing key ($(step path)/secrets/root_ca_key) uses the same password, and you can change that too. In fact, that key is never actually used by the CA so you could even remove that key from your CA deployment and keep it somewhere more secure if you want to.

The password you enter when you request a certificate is actually only used client-side, by the way. When you request a certificate, here's what happens:

1. The CLI requests the escrowed (i.e., password-encrypted) private key for your provisioner from the CA
2. The CLI prompts you for the password to decrypt the private key (client-side... the password is never sent over the network)
3. The decrypted private key is used to sign a short-lived one-time token (a JWT)
4. The token is used to authenticate with the CA and get a certificate

You can actually bypass the password entry altogether, and deploy the private key for your provisioner instead! Furthermore, technically, the CA doesn't even need to escrow the key. If you pop open your $(step path)/config/ca.json you can grab the value of the "encryptedKey" property and then use echo "YOUR_ENCRYPTED_KEY" | step crypto jwe decrypt to decrypt it. You can distribute the decrypted key and, if you want, delete the "encryptedKey" parameter from your ca.json.

If I store the decrypted private key in a file called k.json I can use the it to obtain a certificate like this:

$ TOKEN=$(step ca token foo --provisioner "[email protected]" --key k.json)
✔ Provisioner: [email protected] (JWK) [kid: -6v0dwnSlz2D5opq-B5prQmyD9DhzdJSHMidiu1TjYg]
$ step ca certificate foo foo.crt foo.key --token $TOKEN
✔ CA: https://127.0.0.1:443
✔ Certificate: foo.crt
✔ Private Key: foo.key

You could also use a different provisioner type (e.g., ACME, instance identity documents, kubernetes service accounts) and simply remove the JWK provisioner described here. So there's actually a ton of flexibility around managing all of this stuff.

Hopefully this gives you some idea of what's possible. If you (or anyone else) have any follow-up questions around tailoring a workflow around a specific environment & use case, lemme know. Happy to help!

[haraldkubota]

Well explained and now I know where that client-side password comes from. Thanks to both of you!

[Szparki]

@mmalone should k.json be handled as a secret/password?

[tashian]

@szpark yes, as an unencrypted private key, it should be handled as a secret