Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
OpenSSL::SSL::SSLError using Twitter #404
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):
It seems that, based on my understanding of the OmniAuth code, the following should work for setting an explicit certificate file
For now the only work around I've found is to use
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:
Anyone had the similar problems with oauth?
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
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
So, today I backup the current
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.
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'
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>
The main problems of why this bug appear is because oauth gem is using
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
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)
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:
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
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
http.ca_path = '/etc/ssl/certs'
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.
Similar to above, we fixed this problem by adding a line to
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.