Impossible to store SSL/SSH private Key in vault

[schrd]

Version:

4.1.0

Environment:

Linux

Scenario:

I want to store SSL private keys and SSH private keys in a vault. I think this is what chef-vault is made for. Unfortunately it refuses to encrypt a valid JSON file if there are linebreaks in values.

Steps to Reproduce:

1. generate an SSH key using ssh-keygen -N '' -f demokey -t rsa -q -C ''
2. convert it to json using the following ruby code:

require 'json'
privkey = File.read('demokey')
data = {
  rsa: privkey
}
File.write('demokey.json', JSON.dump(data))

3. create vault: knife vault create testsecrets ssh -A admin1,admin2 -J demokey.json -M client

Expected Result:

I want my key uploaded :-)

Actual Result:

I get an Exception:

ERROR: ChefVault::Exceptions::InvalidValue: Value '-----BEGIN OPENSSH PRIVATE KEY-----
... key data ...
-----END OPENSSH PRIVATE KEY-----
' of key 'rsa' contains non-printable characters. Check that backslashes are escaped with another backslash (e.g. C:\\Windows) in double-quoted strings.

[jblaine]

Please escalate this if at all possible. This was reported January 12, 2021 by me via our paid support with Chef and assigned zendesk ticket ID 26886. The bug still exists in whatever version of vault ships with 21.4.365. We have been having to keep a host around with a super old version of Workstation around just for updating vault items. This is in conflict with the premise that we're supposed to keep Workstation as updated as possible in order to do Chef next-gen cookbook development.

[MarkGibbons]

Interesting, we have always escaped the newlines in our certificates before adding them to vault. I didn't think it was valid to have newline characters in a JSON value. The escaped new lines do turn the certificates into some really ugly strings.

[jblaine]

In our case, we're trying to upload TLS certificates and private keys. And the 2-character sequence '\n' as shown below which has always worked now fails in vault operations. According to https://json.org it is valid JSON.

{"key": "...blahblah...\nblahblah\n...", "cert": "...blah\nblahblah..."}

[MarkGibbons]

yes, I've always seen that work. How odd.

[jblaine]

I also need to add that "don't use Chef Vault" isn't really an acceptable answer coming from Chef support, IMO.

Chef Vault has worked fine for us for 6 years. Someone's change broke it and we're now no longer able to adhere to Chef's stated Best Practice of keeping up with Workstation releases.

[hamarituc]

I have prepared a pull request which at least tries to fix this kind of issues. But there are more cases where it would be convenient to store binary data (e.g., PKCS#12 files, Kerberos Keytabs, unarmored OpenPGP keys, ...) in vaults. These cases are out of the scope of the PR. Allowing arbitrary data would effectively require to undo the changes of #347.

In my opinion it would be worth to discuss this topic, but I have no clue how to start this discussion.

[vivek12chef]

Hello,
My customer (Yahoo-Japan) is chasing me on this issue as this is dragging on for quite some time. Can we please prioritize this as this is impacting their operations now?

[mariastroe]

We also have this problem with TLS certificates and keys stored in chef-vault, but as a workaround we base64 encode the certificate/key, prepare the json, push it to chef-vault and then base64 decode it before using it.

SSL_KEY="$(base64 -w0 ssl.key)"
echo "{\"ssl_key\":\"$SSL_KEY\"}" > key.json
knife vault create secrets ssl -M client -J key.json -A admin1,admin2

And then from chef recipe:

item = chef_vault_item(secrets,"ssl")
ssl_key = Base64.strict_decode64(item['ssl_key'])

file '/etc/ssl/web/ssl.key' do
content "#{ssl_key}"
mode "0400"
end

[vkarve-chef]

This issue is addressed in chef-vault latest version 4.1.4