Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSSL::SSL::SSLError using Twitter #404

Closed
mateomurphy opened this issue Jul 20, 2011 · 17 comments
Closed

OpenSSL::SSL::SSLError using Twitter #404

mateomurphy opened this issue Jul 20, 2011 · 17 comments

Comments

@mateomurphy
Copy link

@mateomurphy mateomurphy commented Jul 20, 2011

I'm running into this issue, similar to #260, but that fix doesn't apply to Twitter, since it uses oauth instead of oauth2 (and rest-client instead of faraday), and the ssl settings in the provider call aren't being passed along.

@CountCulture

This comment has been minimized.

Copy link

@CountCulture CountCulture commented Jul 20, 2011

I'm also getting this. Was fine till a couple of days ago.

This is the stack trace (using Rails 3, REE 1.8.7 on Debian):

/opt/ruby-enterprise-1.8.7/lib/ruby/1.8/net/http.rb:586:in connect' /opt/ruby-enterprise-1.8.7/lib/ruby/1.8/net/http.rb:586:inconnect'
/opt/ruby-enterprise-1.8.7/lib/ruby/1.8/net/http.rb:553:in do_start' /opt/ruby-enterprise-1.8.7/lib/ruby/1.8/net/http.rb:542:instart'
/opt/ruby-enterprise-1.8.7/lib/ruby/1.8/net/http.rb:1035:in request' vendor/bundle/ruby/1.8/gems/oauth-0.4.4/lib/oauth/consumer.rb:164:inrequest'
vendor/bundle/ruby/1.8/gems/oauth-0.4.4/lib/oauth/consumer.rb:197:in token_request' vendor/bundle/ruby/1.8/gems/oauth-0.4.4/lib/oauth/consumer.rb:139:inget_request_token'
vendor/bundle/ruby/1.8/gems/oa-oauth-0.2.5/lib/omniauth/strategies/oauth.rb:31:in request_phase' vendor/bundle/ruby/1.8/gems/oa-core-0.2.5/lib/omniauth/strategy.rb:58:inrequest_call'
vendor/bundle/ruby/1.8/gems/oa-core-0.2.5/lib/omniauth/strategy.rb:41:in call!' vendor/bundle/ruby/1.8/gems/oa-core-0.2.5/lib/omniauth/strategy.rb:30:incall'
vendor/bundle/ruby/1.8/gems/oa-core-0.2.5/lib/omniauth/builder.rb:30:in call' vendor/bundle/ruby/1.8/gems/haml-3.0.25/lib/sass/plugin/rack.rb:41:incall'
vendor/bundle/ruby/1.8/gems/rack-contrib-1.1.0/lib/rack/contrib/jsonp.rb:21:in call' vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/best_standards_support.rb:17:incall'
vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/head.rb:14:in call' vendor/bundle/ruby/1.8/gems/rack-1.2.2/lib/rack/methodoverride.rb:24:incall'
vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/params_parser.rb:21:in call' vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/flash.rb:182:incall'
vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/session/abstract_store.rb:149:in call' vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/cookies.rb:302:incall'
vendor/bundle/ruby/1.8/gems/activerecord-3.0.7/lib/active_record/query_cache.rb:32:in call' vendor/bundle/ruby/1.8/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract/query_cache.rb:28:incache'
vendor/bundle/ruby/1.8/gems/activerecord-3.0.7/lib/active_record/query_cache.rb:12:in cache' vendor/bundle/ruby/1.8/gems/activerecord-3.0.7/lib/active_record/query_cache.rb:31:incall'
vendor/bundle/ruby/1.8/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:354:in call' vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/callbacks.rb:46:incall'
vendor/bundle/ruby/1.8/gems/activesupport-3.0.7/lib/active_support/callbacks.rb:416:in _run_call_callbacks' vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/callbacks.rb:44:incall'
vendor/bundle/ruby/1.8/gems/rack-1.2.2/lib/rack/sendfile.rb:107:in call' vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/remote_ip.rb:48:incall'
vendor/bundle/ruby/1.8/gems/actionpack-3.0.7/lib/action_dispatch/middleware/show_exceptions.rb:47:in call' vendor/bundle/ruby/1.8/gems/railties-3.0.7/lib/rails/rack/logger.rb:13:incall'
vendor/bundle/ruby/1.8/gems/rack-1.2.2/lib/rack/runtime.rb:17:in call' vendor/bundle/ruby/1.8/gems/activesupport-3.0.7/lib/active_support/cache/strategy/local_cache.rb:72:incall'
vendor/bundle/ruby/1.8/gems/rack-1.2.2/lib/rack/lock.rb:11:in call' vendor/bundle/ruby/1.8/gems/rack-1.2.2/lib/rack/lock.rb:11:insynchronize'
vendor/bundle/ruby/1.8/gems/rack-1.2.2/lib/rack/lock.rb:11:in call' vendor/bundle/ruby/1.8/gems/railties-3.0.7/lib/rails/application.rb:168:incall'
vendor/bundle/ruby/1.8/gems/railties-3.0.7/lib/rails/application.rb:77:in send' vendor/bundle/ruby/1.8/gems/railties-3.0.7/lib/rails/application.rb:77:inmethod_missing'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/rack/request_handler.rb:96:in process_request' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_request_handler.rb:513:inaccept_and_process_next_request'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_request_handler.rb:274:in main_loop' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/rack/application_spawner.rb:205:instart_request_handler'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/rack/application_spawner.rb:170:in send' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/rack/application_spawner.rb:170:inhandle_spawn_application'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/utils.rb:479:in safe_fork' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/rack/application_spawner.rb:165:inhandle_spawn_application'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server.rb:357:in __send__' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server.rb:357:inserver_main_loop'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server.rb:206:in start_synchronously' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server.rb:180:instart'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/rack/application_spawner.rb:128:in start' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/spawn_manager.rb:253:inspawn_rack_application'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server_collection.rb:132:in lookup_or_add' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/spawn_manager.rb:246:inspawn_rack_application'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server_collection.rb:82:in synchronize' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server_collection.rb:79:insynchronize'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/spawn_manager.rb:244:in spawn_rack_application' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/spawn_manager.rb:137:inspawn_application'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/spawn_manager.rb:275:in handle_spawn_application' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server.rb:357:insend'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server.rb:357:in server_main_loop' /opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/lib/phusion_passenger/abstract_server.rb:206:instart_synchronously'
/opt/ruby-enterprise-1.8.7/lib/ruby/gems/1.8/gems/passenger-3.0.0/helper-scripts/passenger-spawn-server:99

@mateomurphy

This comment has been minimized.

Copy link
Author

@mateomurphy mateomurphy commented Jul 21, 2011

It seems that, based on my understanding of the OmniAuth code, the following should work for setting an explicit certificate file provider :twitter, consumer_token, consumer_secret, {:client_options => {:ca_file => '/etc/ssl/certs/cacert.pem'}} yet it doesn't.

For now the only work around I've found is to use OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE

@RobinBrouwer

This comment has been minimized.

Copy link

@RobinBrouwer RobinBrouwer commented Jul 25, 2011

I'm having the exact same problem. Couldn't log in via Twitter. Using OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE inside an initializer solved the problem (thanks @mateomurphy), but would love to have a different solution.

@namxam

This comment has been minimized.

Copy link

@namxam namxam commented Jul 25, 2011

I can confirm this problem after upgrading oauth. We have almost the same stack trace except for the ruby version (using 1.8.7, not ree).

@donnykurnia

This comment has been minimized.

Copy link

@donnykurnia donnykurnia commented Jul 26, 2011

I have the same problems since July 15th. The problems only occurred in production server, while in development it run just well.

I have analyze the oauth gem code specifically the file 'lib/oauth/consumer.rb' and it use the correct certificate file from /etc/ssl/certs/ca-certificates.crt. So @CountCulture, please check your certificate file to see if it contain the updated Root CA certificate.

I suspect that the bug is caused by newrelic, here is the backtrace:

/home/vortex/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:586:in connect' /home/vortex/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:586:inconnect'
/home/vortex/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:553:in do_start' /home/vortex/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:542:instart'
/home/vortex/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:1035:in request_without_newrelic_trace' newrelic_rpm (2.13.4) lib/new_relic/agent/instrumentation/net.rb:11:inrequest'
newrelic_rpm (2.13.4) lib/new_relic/agent/method_tracer.rb:141:in trace_execution_scoped' newrelic_rpm (2.13.4) lib/new_relic/agent/instrumentation/net.rb:10:inrequest'
oauth (0.4.4) lib/oauth/consumer.rb:164:in `request'

Anyone had the similar problems with oauth?

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Jul 31, 2011

Same problem here, glad to hear there are others with the same issue. I guess we'll just use OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE until a proper fix is found.

@donnykurnia

This comment has been minimized.

Copy link

@donnykurnia donnykurnia commented Aug 3, 2011

I finally make the twitter auth working in the production server. After digging around the omniauth code from the backtrack in the exception notification, I finally figured out that the /etc/ssl/certs/ca-certificates.crt file in the production server is fail to verify the new twitter certificate.

It's turn out that I have the latest certificate file, but with different name. I download it from http://certifie.com/ca-bundle/ca-bundle.crt.txt and put it as /etc/ssl/certs/ca-bundle.crt.

So, today I backup the current /etc/ssl/certs/ca-certificates.crt file, then do this:

cp /etc/ssl/certs/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt

Suddenly, the twitter auth running without any exception report. It run normally in production server just like in development one.

@donaldpiret

This comment has been minimized.

Copy link

@donaldpiret donaldpiret commented Aug 4, 2011

Same issue here, updating to the latest root certificates using the update-ca-certificates ubuntu command has no effect either. Guess it's verify_none for me as well :(

@donnykurnia

This comment has been minimized.

Copy link

@donnykurnia donnykurnia commented Aug 4, 2011

For those that still have the problems, try to run this small programs via irb or rails console

require "net/https"
require "uri"

uri = URI.parse("https://api.twitter.com/")
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_PEER
http.ca_file = '/etc/ssl/certs/ca-certificates.crt'
http.verify_depth = 5
request = Net::HTTP::Get.new(uri.request_uri)
response = http.request(request)

Also, try to change

http.ca_file = '/etc/ssl/certs/ca-certificates.crt'

with

http.ca_path = '/etc/ssl/certs' if File.exists?('/etc/ssl/certs') # Ubuntu

see if you still got an error:

OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

or the request can run and returning:

#<Net::HTTPOK 200 OK readbody=true>
@donnykurnia

This comment has been minimized.

Copy link

@donnykurnia donnykurnia commented Aug 4, 2011

The main problems of why this bug appear is because oauth gem is using ca_file instead of ca_path.
It is set in the line 317 of the file lib/oauth/consumer.rb in the gem oauth version 0.4.5:

      if @options[:ca_file] || CA_FILE
        http_object.ca_file = @options[:ca_file] || CA_FILE
        http_object.verify_mode = OpenSSL::SSL::VERIFY_PEER
        http_object.verify_depth = 5
      else
        http_object.verify_mode = OpenSSL::SSL::VERIFY_NONE
      end

CA_FILE by default is either /etc/ssl/certs/ca-certificates.crt or /usr/share/curl/curl-ca-bundle.crt:

  class Consumer
    # determine the certificate authority path to verify SSL certs
    CA_FILES = %w(/etc/ssl/certs/ca-certificates.crt /usr/share/curl/curl-ca-bundle.crt)
    CA_FILES.each do |ca_file|
      if File.exists?(ca_file)
        CA_FILE = ca_file
        break
      end
    end
    CA_FILE = nil unless defined?(CA_FILE)
@ahx

This comment has been minimized.

Copy link

@ahx ahx commented Aug 4, 2011

donnykurnia's fix worked for me. Updating /etc/ssl/certs/ca-certificates.crt has solved the issue (on Debian lenny)

@mateomurphy

This comment has been minimized.

Copy link
Author

@mateomurphy mateomurphy commented Aug 4, 2011

Hi Donny,

Thanks for the info! I had tried updating my ca cert but the one I grabbed didn't work either; the one you posted does.

Another option, if you don't want to clobber your certificate file, is to point oauth to the correct one:

provider :twitter, consumer_token, consumer_secret, {:client_options => {:ca_file => '/etc/ssl/certs/ca-bundle.crt'}}

In any case, I think this should be considered an oauth bug, which should have an option of using the ca_path instead of just the ca_file

@donnykurnia

This comment has been minimized.

Copy link

@donnykurnia donnykurnia commented Aug 4, 2011

Glad to help. Anyone know how to contact the oauth gem authors about this bug? I cannot find any contact beside email in http://rubygems.org/gems/oauth

In my shared dreamhost account, the /etc/ssl/certs/ca-certificates.crt file also failed to verify the new twitter api certificate. The little test program above only run with either:

  http.ca_path = '/etc/ssl/certs'

or

  http.ca_file = '/etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.pem'

This left the dreamhost shared users to use @mateomurphy solution above if want to use twitter omniauth.

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Aug 5, 2011

Similar to above, we fixed this problem by adding a line to lib/oauth/consumer.rb which sets the path:

if @options[:ca_file] || CA_FILE
  http_object.ca_file = @options[:ca_file] || CA_FILE
  http_object.verify_mode = OpenSSL::SSL::VERIFY_PEER
  http_object.verify_depth = 5
else
  http_object.verify_mode = OpenSSL::SSL::VERIFY_NONE
end

http_object.ca_path =  "/etc/ssl/certs" # <- added line

This worked locally (Ubuntu) in development mode, but not on Dreamhost shared hosting in production mode (as @donnykurnia notes above), so we're back to verify_none for that. Kind of ironic since it's for the live (test) site that this may actually mean something.

@mateomurphy

This comment has been minimized.

Copy link
Author

@mateomurphy mateomurphy commented Aug 5, 2011

you might need to remove the part that sets the ca_file for this to work, as the library probably perfers using ca_file when both are available.

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Aug 5, 2011

No dice. I've wasted too much time on this, and we're a ways away from deploying this so I'll just wait till a proper fix comes in.

@mbleigh

This comment has been minimized.

Copy link
Contributor

@mbleigh mbleigh commented Nov 2, 2011

Strategy specific, no longer applies to this repo.

@mbleigh mbleigh closed this Nov 2, 2011
@xdite xdite mentioned this issue Feb 13, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.