Private key stored in node attributes

[troyready]

Does the private key need to persist on the node attributes, since it can be read from disk? It would be nice to be able to remove it.

(btw -- thanks for all of your great work on this)

[thoutenbos]

There is actually two different private keys. The one in the node attributes is used to authenticate the client to the Boulder API and to sign the API requests. It's saved to be persistent once generated.

The private key for the certificate is a different key, and is saved in the key file, not in the node attributes.

[troyready]

Ah, got it. Thanks for the explanation.

Would you be interested in a PR to optionally save that key on the filesystem as well? Would that make sense as something controlled by an attribute?

[sbotman]

Sounds like a nice option...

[acoulton]

Saving this to filesystem would help me too, happy to look at a PR. It looks most logical to trigger this within the acme_client library method, but that implies using plain ruby File.read / File.write to manage the key file rather than defining it as a chef file resource. Would that be OK?

Alternatively, I could look at refactoring the key creation out of the acme_client - possibly it could be defined as a resource in its own right in the default recipe?

[thoutenbos]

Using the file resource would be the preferred way for me, but I wouldn't want the runlist order getting in to play with adding it to the default recipe. How about adding it in the certificate provider, similar to the way the certificate private key is generated if it doesn't exist yet.

Then it would become something like:

1. Use the key from the node attribute if it is set
2. Use the key from the file if it exists
3. Generate a new key and save it to attribute/file

Does that sound sensible?

[runningman84]

What about backing up certs/keys to s3?

It would be really cool if I could destroy a webserver and rebuild it and the ssl keys would be gathered from s3...

[cixelsyd]

Another method would be to save the API key to an encrypted data bag. You could keep it there, and that would provide a small amount of protection. This would cause a specific round-trip to the chef server to retrieve it on each run, however. There's also chef-vault as well.

[axos88]

Not sure what the upside of this would be since you can automatically regenerate the ssl keys anyways.

[thoutenbos]

Should be fixed once #63 is in

[acoulton]

Great, thanks very much