Bug #12348


PKey::EC.public_key returns EC::Point

Added by mcr (Michael Richardson) over 6 years ago. Updated almost 6 years ago.

Target version:
ruby -v:
ruby 2.4.0dev (2016-04-27 openssl-110-v1 54798) [x86_64-linux]


It appears that the EC subclass returns something isn't recognized as a public key (not a subclass of OpenSSL::PKey::PKey) when asked for its' public_key:

ext-ruby-2.4-ssl :040 > key ='X25519')
 => # 
ext-ruby-2.4-ssl :041 > key.generate_key
 => # 
ext-ruby-2.4-ssl :042 > key.public_key
 => #>>> 

The result can not be assigned as a certificate public key:

ext-ruby-2.4-ssl :043 > root_ca  =
 => #, issuer=#, serial=#, not_before=nil, not_after=nil> 
ext-ruby-2.4-ssl :044 > root_ca.public_key = key.public_key
TypeError: wrong argument (OpenSSL::PKey::EC::Point)! (Expected kind of OpenSSL::PKey::PKey)

which is how I understand the RSA and DSA objects work (see: )


ext-ruby-2.4-ssl :045 > root_ca.public_key = key           
 => #>> 

is just fine. However, later on, one runs into that:

NoMethodError: undefined method `private?' for #OpenSSL::PKey::EC:0x0000000453e388

which is more likely a bug in OpenSSL::X509::Certificate.

See #12324 for branch being used, also tested with 2.3.0, and using secp112r1 curve:

2.3.0 :026 >     root_ca.sign(root_key,
NoMethodError: undefined method `private?' for #

a simple monkey patch solved this issue, but reveals issues deeper in EVP which are unique to X25519.

Updated by hsbt (Hiroshi SHIBATA) over 6 years ago

  • Status changed from Open to Assigned
  • Assignee set to rhenium (Kazuki Yamaguchi)

Updated by rhenium (Kazuki Yamaguchi) almost 6 years ago

  • Status changed from Assigned to Closed

There is an inconsistency with other OpenSSL::PKey classes in #public_key method. However I don't think it's worth breaking backwards compatibility in order to align the behavior with the other classes, as OpenSSL::PKey::{RSA,DSA,DH}#public_key are useless in normal use cases.

NoMethodError: undefined method `private?' for #OpenSSL::PKey::EC:0x0000000453e388

This should have been fixed by r55098.


Also available in: Atom PDF