OpenSSL error if private key does not match used public key #43

Closed
moserke opened this Issue Sep 11, 2013 · 8 comments

Comments

Projects
None yet
8 participants
Contributor

moserke commented Sep 11, 2013

"OpenSSL::PKey::RSAError: padding check failed" error received if the private key used to try and decrypt the value is not the pair of the public key used to encrypt the value. This can be received if the client/admin pem is regenerated after doing the encryption with chef-vault and the vault is not updated.

This is a VALID error, but need to add a better exception message!

merqlove commented Nov 9, 2013

+1

I get this even when I (think that I) am using the same key for encryption and decryption.

$ knife encrypt create secrets test '{"test":"foo"}' --admins user1 --mode client
$ knife encrypt update secrets test '{"test":"foo"}' --admins user1,user2 --mode client
ERROR: OpenSSL::PKey::RSAError: padding check failed

Would it be possible that one part of the code uses my client's key and the other part the one of my user? Both have a different public key (verified by calling knife (node|client) show user1

Any idea?

Contributor

moserke commented Dec 2, 2013

This is a classic case of how the users and clients are stored for authentication. They are actually different entities in the chef server and as such each has it's own public/private key pair for authentication. This is because users are not just for the webui, they are also used for knife access.

What is happening here is that when you do a knife encrypt create/update --admins this tells chef-vault to look for a user with that name. Therefore your commands below are encrypting for the user "user1" but you are using the private key of client "user1" which does not match and hence you get the OpenSSL error.

You have a couple options here:

  1. Do not have clients and users with the same name, this can cause confusion like you are seeing
  2. Use the private key of the user1 user on your box, then your public/private key pairs will match
  3. Delete the user1 user and only use the client, to do this you would want to create a client/node pair called user1 and instead of using --admins, use --search "name:user1"

In the next version coming soon chef-vault will first look for a user named what is given in --admins, if it can't find a user it will then look for a client named that. This eliminates the need to create a node and client named the same and lets you still user --admins, instead of --search.

Hope this clears it up!!

sysbot commented Dec 15, 2013

+1 for "In the next version coming soon chef-vault will first look for a user named what is given in --admins, if it can't find a user it will then look for a client named that"

sysbot commented Dec 15, 2013

I spoke too soon. Look like searching for client from --admins [1] is already fixed.

[1] cd0f1ba

dzabel commented Jun 13, 2014

+1 "This is a VALID error, but need to add a better exception message!"

Suggestion: give information about the vault item that has failed.

galindro commented Sep 1, 2014

+1

@jf647 jf647 self-assigned this Feb 6, 2015

jf647 pushed a commit that referenced this issue Feb 6, 2015

Emit a human-friendly error message when the vault is encrypted for a…
… node, but the private key can't decrypt the shared secret


Closes #43
Contributor

jf647 commented Feb 6, 2015

Better late than never, I suppose:

> knife vault show test item -z -c knife.rb -u one -k one.pem
ERROR: ChefVault::Exceptions::SecretDecryption: test/item is encrypted for you, but your private key failed to decrypt the contents.  (if you regenerated your client key, have an administrator of the vault run 'knife vault refresh')

This will make it into the next release, which will be v2.4.1 or v2.5.0 depending on whether any of the issues I can get through add functionality or just fix bugs.

@jf647 jf647 closed this Feb 6, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment