"uninitialized constant OpenSSL::PKey::EC" from Ruby on CentOS 6.6 - ruby

Question

I have a Rails server application that uses the openid_connect gem. When I attempt to run it on CentOS 6.6, I get:
uninitialized constant OpenSSL::PKey::EC
Here is the full stacktrace:
$ rails server
/home/foo/.rvm/gems/ruby-2.1.3/gems/json-jwt-1.5.1/lib/json/jwk/jwkizable.rb:69:in `<top (required)>': uninitialized constant OpenSSL::PKey::EC (NameError)
from /home/foo/.rvm/gems/ruby-2.1.3/gems/json-jwt-1.5.1/lib/json/jwt.rb:102:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object/id_token.rb:1:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object.rb:7:in `block in <top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object.rb:6:in `each'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object.rb:6:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/connect_object.rb:52:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect.rb:85:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:76:in `require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:76:in `block (2 levels) in require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:72:in `each'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:72:in `block in require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:61:in `each'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:61:in `require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler.rb:134:in `require'
from /home/foo/tmp/openid_connect_sample/config/application.rb:7:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:53:in `require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:53:in `block in <top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:50:in `tap'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:50:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'
What does this mean and how I can I get past it?

Answer 1

This problem stems from Red Hat's refusal to include (for fear-of-patent-litigation reasons) certain Elliptic Curve (EC) algorithms in CentOS' default build of OpenSSL.
Note: According to #Cal's answer, CentOS 6.7 does not have this issue.
The openid_connect gem is dependent on the json-jwt gem, which uses one of those not-included algorithms.
Therefore, you need to rebuild a new version of OpenSSL that includes the needed algorithms.
These are the steps I followed (adapted from here) to build a new OpenSSL on my machine:
cd /usr/src
wget https://www.openssl.org/source/openssl-1.0.1l.tar.gz
yum install autoconf automake (you probably already have these installed)
tar zxvf openssl-1.0.1l.tar.gz
cd openssl-1.0.1l
export CFLAGS="-fPIC"
./config --prefix=/opt/openssl shared enable-ec enable-ecdh enable-ecdsa
make all
make install
Now, your Ruby is probably still linked against the old OpenSSL library, so you'll need to rebuild it to link to the new one.
Are you using rvm? Then great! Any new Rubies you install will build against the new OpenSSL. rvm remove your Ruby and re-install it (or simply install a different ruby version).
Not using rvm? Then I guess you'll need to rebuild Ruby the traditional way. But you probably already know how to do that, right? If not, you'll need to look in a different tutorial, because we can't cover that here.
Now reinstall bunder and do a bundle install, and your rails server should now run successfully.
(If anyone has corrections or clarifications to offer, please leave a comment and I'll make edits as necessary.)

Answer 2

I ran into this same problem with CentOS 6.6. But I didn't want to recompile a custom openssl and ruby to fix this. I didn't take very good notes because I tried so many things, but it appears that an update to all of the latest & greatest packages to CentOS 6.7 solves the problem.
Here are a few relevant package versions I have:
openssl098e-0.9.8e-18.el6_5.2.x86_64
openssl-1.0.1e-42.el6.x86_64
openssl-1.0.1e-42.el6.i686
openssl-devel-1.0.1e-42.el6.x86_64
glibc-2.12-1.166.el6_7.3.x86_64
kernel-2.6.32-573.7.1.el6.x86_64
After updating these packages, rebooting, and reinstalling my bundle the json-jwt gem worked perfectly.
This was our production machines, and I believe the ruby standard libs were compiled from source, then created as a custom RPM.
Our build server uses RVM, and this ended up being more of a pain. The RVM installer kept pulling binaries for centos, and the same failure came back again.
Found remote file https://rvm.io/binaries/centos/6/x86_64/ruby-1.9.3-p484.tar.bz2
I forced a source recompile like this:
rvm reinstall --disable-binary ruby-1.9.3-p484
And I noticed a very wonderful looking message:
#applying patch .rvm/patches/ruby/ssl_no_ec2m.patch.
That patch file has some C macro conditions that appear to exclude some EC related code.
And that worked! I also noticed that ruby's openssl.so has a lot of EC related symbols in it. The previously packaged centos ruby did not have these:
$ cd ~/.rvm/rubies/ruby-1.9.3-p484/lib/ruby/1.9.1/x86_64-linux
$ strings openssl.so |grep _EC
PEM_write_bio_ECPKParameters
i2d_ECPKParameters
PEM_read_bio_ECPKParameters
d2i_ECPKParameters
PEM_write_bio_ECPrivateKey
i2d_ECPrivateKey_bio
i2d_EC_PUBKEY_bio
PEM_write_bio_EC_PUBKEY
PEM_read_bio_ECPrivateKey
PEM_read_bio_EC_PUBKEY
d2i_ECPrivateKey_bio
d2i_EC_PUBKEY_bio
OPENSSL_1.0.1_EC
EVP_PKEY_assign_EC_KEY
OP_SINGLE_ECDH_USE
If I had to guess, the recompile against my new openssl 1.0.1 package must have triggered some C macros that opened up some kind of alternative algorithm that isn't legally protected.
If you check your openssl.so for symbols and it doesn't have all of these _EC related stuff, that's probably an issue.