OpenSSL::PKey::RSAError: Neither PUB key nor PRIV key: unsupported #129
Comments
|
Hi @thibaudgg, It is happening during initialization and based on the error message it looks like the keys_content that was passed is not valid: https://github.com/railslove/epics/blob/v1.8.1/lib/epics/client.rb#L12 epics expects a json string here which it can decrypt with the passphrase passed in the second parameter So it might also be caused by the passphrase not matching the one defined during initial setup. |
|
Hi @tobischo, thank you for looking into it and for your detailed answer. My main concern is that everything is running well under the Heroku-20 Stack which ships with openssl 1.1.1f-1ubuntu2.16, all the rest is identical (same credentials and Ruby/Gems version) and that for many different banks credentials. Would it be that OpenSSL 3 is pickier about the I just used the keys that Epics gave me when I set up each Banks connection ( |
|
Hi @thibaudgg just to rule out all the options before also investing a lot of time here on trying to recreate the issue: So the keys and password for the keys is provided in exactly the same way and also reaches the code in exactly the same way between the different versions on heroku? Did you by any chance manage to recreate the issue outside of heroku, e.g. inside of a docker container? |
|
Note for later: This might be helpful |
Correct, identical keys and code, only the Heroku stacks changed from 20 to 22. I just re-tested it now, so I'm confident this is the only changing piece.
Sadly not, I'm not using docker and haven't much experience running it either. |
|
Ok, so I managed to recreate it by using ubuntu:22.04 as a base image, installing openssl3 and ruby3, as well as epics I am getting the same error there, however that does not yet provide a solution. Edit: It works fine with ruby3 and openssl 1.x.x, so indeed something that changed towards openssl 3 |
|
This also looks related: ruby/openssl#369 |
|
Ok, so from what I could notice so far: See: Line 269 in 06f7e63 While that worked nicely for openssl 1.1.1, it does not appear to behave as intendend for openssl 3. When I adapt the code to run with individually initialized ciphers per key to be decrypted, it works just fine |
|
I created a PR in #132 which solved the key loading issue for me |
|
Hey @tobischo, thanks for looking into it. I just gave a try to your PR #132 on the The only one that fails is raising: I checked again the same bank with the latest version of |
|
Is there anything obviously different between the banks? E.g. different key sizes? If it is working for all of them but one, it will be rather difficult to debug this. Considering that it has been working with |
|
@tobischo I just gave another try to your PR on the As you mentioned, I also suspect that something wasn't up-to-date on the bank server side, as everything was quite similar (key sizes) between the one failing and the others. Maybe my previous test triggered some alarms and they already made the required update (even if that seems like a fast resolution for a bank 😅). So from my side, I would give a GO for your PR. 👍🏻 Do you have an idea about when it will be merged and a new gem version will be released? Thanks a lot for your work! 💪🏻 |
|
Unfortunately not 😬 I already have a PR waiting for that and we could probably include it into the v2.0.0 of this gem then - no idea of the timeline for this though |
|
@tobischo ok, no worries, I can use your PR branch in the meantime. |
|
@thibaudgg It is merged now. Will try to get it released. See #131 on that. Closing this here for now |
|
Hey @tobischo, I encountered this issue again with two different Swiss banks this week. It could be my fault because I generated the keys with the 1.8.1 gem version and when I initiate the Epics client with the latest master version (2.1.1) I'm getting again this issue: While trying to debug the issue, I found this one interesting tidbit when printing the class Epics::Key
attr_accessor :key
def initialize(encoded_key, passphrase = nil)
print encoded_key
if encoded_key.kind_of?(OpenSSL::PKey::RSA)
self.key = encoded_key
else
self.key = OpenSSL::PKey::RSA.new(encoded_key)
end
end
...
endThe encoding of the Do you think that restarting the INI key process with the latest master version (2.1.1) instead of 1.8.1 would solve this issue, or something is still wrong here? Thanks for your support! |
|
Could it be linked to that change? 131c1bd All existing keys (that I also generated with 1.8.1) are still working fine on the latest master version (2.1.1) so I wonder if that's those new banks having issues... |
|
Both versions are executed with the same ruby and openssl version? |
|
Yes, both are on Ruby 3.2.2 and the same openssl version (LibreSSL 3.3.6). |
|
Then it is likely related |
|
Were those keys also generated on openssl 3? So right now I am wondering about how to best recreate the issue to find a potential solution. So right now the things to try would be: If both of these work it might actually additionally be related to the ruby/openssl version used to originally generate the keys |
Yes, but using the 1.8.1 version, Ruby 3.2.2 and openssl version (LibreSSL 3.3.6).
From my experience/testing, generating and saving the final key (HPB command) works with 1.8.1 (didn't check with 2.1.1 as you can only do it one with the bank) and doing the HAA command was ok, but reinitializing the client with the final key was then failing with the error above on both versions. Is it helpful? 😬 |
|
Alright, so it works nicely against openssl 1.1.1, but it fails against openssl 3.0.9 Considering that, my immediate recommendation would be to go with openssl 1 and not openssl 3. As far as I can tell, ruby does still not properly support openssl3... Interestingly... with what you described now and with what I have observed now, going back on the change in 131c1bd is also not an option, since it fails with: /usr/local/bundle/gems/epics-1.8.1/lib/epics/client.rb:110:in `set_key': rsa#set_key= is incompatible with OpenSSL 3.0 (OpenSSL::PKey::PKeyError) |
|
So you can generate the keys relatively easily without needing anything further gem 'epics', '= 1.8.1'
require 'epics'
client = Epics::Client.setup(
"<example>",
"<example>",
"<example>",
"<example>",
"<example>",
)
client.save_keys("epics.key")and then you can load it using: gem 'epics', '= 2.1.1'
require 'epics'
keys = File.read('epics.key')
client = Epics::Client.new(
keys,
"<example>",
"<example>",
"<example>",
"<example>",
"<example>",
)Additionally for simplicity it can be loaded using: passphrase = '<example>'
gem 'epics', '= 1.8.1'
require 'epics'
keys = File.read('epics.key')
json_keys = JSON.load(keys)
# A006
# X002
# E002
data = Base64.strict_decode64(json_keys['E002'])
salt = data[0..7]
data = data[8..-1]
cipher = OpenSSL::Cipher.new("aes-256-cbc")
cipher.decrypt
cipher.key = OpenSSL::PKCS5.pbkdf2_hmac_sha1(passphrase, salt, 1, cipher.key_len)
result = cipher.update(data) + cipher.finalThe odd part here is, that if I generated the key with openssl 3 on epics 1.8.1 I get: As far as I can tell the first line appeared to be broken, when decrypted, but otherwise I could read the key. I am not sure if that would then solve the entire issue, however loading the keys would technically be possible if you could get them fixed that way. Based on what I tried, in some openssl versions it works opening the key generated with epics 1.8.1 also with epics 2.1.1. Specifically this is the case for openssl 1.1.1t. Generating keys with epics 2.1.1 and opening them with epics 2.1.1 on openssl3 worked without an issue. That means, the "best" way for you to get them safely transformed might be the following: Execute the following for epics 1.8.1, since that is where you generated the keys: gem 'epics', '= 1.8.1'
require 'epics'
keys = File.read('epics.key')
client = Epics::Client.new(
keys,
"<example>",
"<example>",
"<example>",
"<example>",
"<example>",
)
client.keys.each do |key_type, key|
File.open("#{key_type}.pem", 'w+').tap {|f| f.write(key.key.to_pem)}.close
endThis will extract the keys in Then as a next step you should be able to do the following (note that the setup is just there to generate some initial keys without requiring to load the original ones) gem 'epics', '= 2.1.1'
require 'epics'
client = Epics::Client.setup(
"<example>",
"<example>",
"<example>",
"<example>",
"<example>",
)
['A006', 'E002', 'X002'].each do |key_type|
base_key = File.read("#{key_type}.pem")
client.keys[key_type] = Epics::Key.new(base_key)
end
client.save_keys('new_epics.key')That key file should then be openable with a ruby compiled against openssl3 with epics 2.1.1 |
|
@tobischo thanks a lot for your detailed answer, I was able to fix both keys with the pem files. Everything works great now! 🥇 |
I tried to upgrade to the latest Heroku-22 Stack, which ships with OpenSSL 3 and got the following error:
Heroku mentions this:
I wonder if this is an issue with the Bank servers as it is failing with the same error on all the different ones I connect to, which tends to point to an implementation problem in epics.
The text was updated successfully, but these errors were encountered: