Skip to content
This repository

SSLError with upgrade from 0.2.0 to 0.2.1 #260

Closed
eric-hu opened this Issue April 07, 2011 · 59 comments
eric-hu

Omniauth 0.2.1 changes its dependency on the Faraday gem from 0.5.7 to 0.6.0

This change forces https connections to check for valid certificates. In development mode, my program was previously handling Facebook authentications as expected with 0.2.0. During authentications, the console displays

warning: peer certificate won't be verified in this SSL session

I assume that by default, SSL certificate checking was disabled. With Omniauth 0.2.1/Faraday 0.6.0, SSL certificate checking seems to be enabled and I get the following error on a Facebook authentication:

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

This may be out of the scope of Omniauth and could be considered a Faraday issue. I just wanted to post it here since I feel it deserves at least a wiki entry. I'll post more as I search for ways to get the newest version working with SSL cert checking.

For now, reverting to Omniauth 0.2.0 works (without SSL cert checking), so I'll be using that to finish some feature development first.

In looking for a solution, I found some questions on StackOverflow that suggested monkey-patching faraday to ignore SSL certifications. I also found another solution that suggested pointing rails to CA certificates for Firefox. I was under the impression that the always_verify_ssl_certificates gem would do something similar, but it seems to require some customization to use system certificates.

Sorry for the rambling post but I just wanted to share the issue I've had and the progress I've made

Alex Kremer

I can confirm we also ran into this issue when upgrading to 0.2.1. Our solution for now was to add an initializer that does the following:

OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE

But clearly this isn't a practical or desirable solution. I'd also like to see a wiki entry that specifically solves the issue with Facebook.

Alex Kremer

I just posted the following on the Stackoverflow thread about this issue.

The real problem is that Faraday (which Omniauth/Oauth use for their HTTP calls) is not setting the ca_path variable for OpenSSL. At least on Ubuntu, most root certs are stored in "/etc/ssl/certs". Since Faraday isn't setting this variable (and currently does not have a method to do so), OpenSSL isn't finding the root certificate for Facebook's SSL certificate.

I've submitted a pull request to Faraday which will add support for this variable and hopefully they will pull in this change soon. Until then, you can monkeypatch faraday to look like this or use my fork of Faraday. After that, you should specify version 0.3.0 of the OAuth2 gem in your Gemspec which supports the passing of SSL options through to Faraday. You'll then be able to properly fix this issue by just adding the following to your Omniauth initializer:

Rails.application.config.middleware.use OmniAuth::Builder do
    provider :facebook, FACEBOOK_KEY, FACEBOOK_SECRET, {:client_options => {:ssl => {:ca_path => "/etc/ssl/certs"}}}
end

So, to recap:

  1. Faraday needs to be updated to support SSL ca_path
  2. Your app needs to use OAuth2 version 0.3.0. You may need to fork omniauth since it currently has a minor version dependency in the 0.2.x tree.
  3. Modify your provider initializer to point to your system's certificate path ("/etc/ssl/certs" on Ubuntu et al)

Michael/OmniAuth team: Could you bump the oauth2 dependency to 0.3.0 in the next release so the SSL options can be passed through? 0.2.x doesn't support it. Thank you!

Gady

I ran into the same problem when deploying to Heroku

Erik Michaels-Ober
Collaborator

I just merged your pull request into the Faraday master. I'll talk to @technoweenie and @mislav about pushing out a new Faraday gem that includes your patch and some other small fixes to the 0.6.0 release. That will take care of problem number 1 above.

As for number 2: I've already released version 0.3.0 of the oauth2 gem, so @mbleigh just needs to update the omniauth gemspec to point to it.

And number 3 is up to you!

Erik Michaels-Ober
Collaborator

I just released faraday 0.6.1: http://rubygems.org/gems/faraday

Alex Kremer

Thanks! Once the oauth2 dependency is sorted in omniauth, this should probably be added as a wiki article to ensure folks are passing the right ca_path and not turning off peer verification for no good reason...

eric-hu

Thanks to both of you! I agree with akremer--I can write up the wiki article when the oauth2 dependency is raised to 0.3.0

I wasn't able to point Omniauth 0.2.1 to the right certs using akremer's code above. I believe this is because Omniauth0.2.1 is using Oauth2 0.2.0. For now, I'm still just bypassing ssl certs by using omniauth 0.2.0 as I'm not yet in production.

In the mean time, for any other linux users trying to get this to work, you can find out your ssl certs directory with openssl version -a in a terminal window. For me on Ubuntu 10.10, this command reports /usr/lib/ssl (add /certs to see the certificates).

However, ls -l /usr/lib/ssl/certs shows this directory is a link to /etc/ssl/certs, which akremer mentioned in an earlier post. Either will give you the same result.

Michael Bleigh mbleigh closed this in 76553b9 April 15, 2011
Kimball Bighorse

Still seeing an error with faraday 0.6.1, oauth 0.3.0 and omniauth 0.2.2:
https://gist.github.com/925039

On the server:

$ openssl version -a
OpenSSL 0.9.8k 25 Mar 2009
built on: Fri Dec 3 22:53:56 UTC 2010
platform: debian-amd64
options: bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) blowfish(ptr2)
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM
OPENSSLDIR: "/usr/lib/ssl"
$ ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Jan 15 22:06 /usr/lib/ssl/certs -> /etc/ssl/certs

Alex Kremer

run openssl s_client -CApath /etc/ssl/certs -connect graph.facebook.com:443 -- if your verify return code isn't 0, you're missing the digicert root certificate and need to install that.

eric-hu

created a wiki entry with most of this information: https://github.com/intridea/omniauth/wiki/Setting-up-SSL-certificate-locations-in-Linux

Please edit it if you find anything to be vague or verbose.

I didn't include anything about the missing digicert root certificate yet, but that should be added once kbighorse verifies that works for him (and hopefully has some instructions on installing the certificate).

Mislav Marohnić

Faraday project needs such docs. @eric-hu, I would be grateful if you documented this cert stuff in the Faraday wiki. Then, Omniauth wiki can refer to the original docs in the Faraday wiki.

People should be aware that, if they consume APIs over SSL they need to do it with proper certificate verification

Kimball Bighorse

Return code is 0: https://gist.github.com/926579, unfortunately. Thanks for the tip though!

eric-hu

@mislav I'd be happy to, especially since most solutions floating around to this problem are essentially "disable SSL".

I haven't used Faraday directly, though. I'm looking around for usage examples, but if you know some or can come up with some simple ones, that would save me a lot of time.

Nathalie Ek
nat0 commented April 24, 2011

I also have see the same issue with omniauth 0.2.4, oauth 0.4.1 and faraday 0.6.1 and the command suggested by @akremer returns 0 so the ssl cert is working. I have also set the ca_path but still getting the error. Any ideas?

Alex Kremer

Are you sure your initializer is set correctly as in the above example? If so and you're still getting an error, I'd try writing a simple app with just Faraday that makes a call to https://graph.facebook.com and try to pass the ca_path parameter. If it errors out at that point, at least we know where to dig further. Another thing to check might be that apache/nginx or whatever you use can actually read from your ca_path.

Nathalie Ek
nat0 commented April 24, 2011

The server used is Mongrel and the distro is Fedora. The problem does not occur on my ubuntu box and if I set ca_path there it solves all problems. Fedora has a bundle file but as i said the command above returns status 0. I have even tried to copy all the certs from Ubuntu to Fedora but that did not help either.

Alex Kremer

Try /etc/pki/tls/certs or /usr/share/ssl/certs on Fedora and make sure the apache user can read from there. If that doesn't work, try passing :ca_file (instead of :ca_path) and point it to /etc/pki/tls/certs/ca-bundle.crt - again, make sure your web runner can read the file.

Nathalie Ek
nat0 commented April 27, 2011

@akremer, thank you VERY much. Passing :ca_file and providing the file path did the trick :)

eric-hu

@nat0 Was using the paths alone insufficient?

I'd just like to know so the wiki can have this information for other Fedora users.

Matthias Jakel

I have the same problem with Ubuntu (on Heroku). I define

:ca_path => '/etc/ssl/certs'

But it isn't working.

Kimball Bighorse

@akremer, sounds like my issue is still unresolved?

eric-hu

@matthiasjakel I'm familiar with Heroku but haven't deployed any applications to it yet. Is that where the path for SSL certs is on the Heroku server? I couldn't find what OS a Heroku dyno runs (if it even does).

A solution for you would be to get the certs bundle from a CA third party, like Godaddy's and upload it as part of your project. Then point your CA_PATH (and possibly CA_FILE) there. I'd personally prefer to use SSL certs that Heroku provides if they're available--I assume they'll keep them up to date and that will be one less thing for you to manage. Can you run the openssl version -a command on Heroku's server?

eric-hu

@kbighorse what OS are you using? You may require an OS-specific solution like nat0.

Another possible explanation--I noticed that your openssl version is a little older than mine (running on ubuntu 10.10, but openssl should be update-able independently)

OpenSSL 0.9.8o 01 Jun 2010
built on: Thu Feb 10 01:47:31 UTC 2011
platform: debian-amd64
options:  bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) blowfish(ptr2) 
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM
OPENSSLDIR: "/usr/lib/ssl"

Perhaps your certs are out of date?

Mislav Marohnić

You can't run commands on the Heroku platform. @matthiasjakel, you should ask Heroku support for the location of the CA bundle.

Matthias Jakel

@mislav yes, you can. You have to run

heroku console

and if you want to make a shell request you have to set your request in backticks

`openssl version -a`

the path is /usr/lib/ssl/certs and there are many different files in there. I don't know which one i should use.

00673b5b.0
02b73561.0
0481cb65.0
052e396b.0
06d75f4b.0
0c364b2d.0
0dbd0096.0
0e82f83a.0
10d149a2.0
111e6273.0
1155c94b.0
11a09b38.0
11f154d6.0
124bbd54.0
128b9c8d.0
12d55845.0
1689a10b.0
17b51fe6.0
19899da5.0
1dac3003.0
1dcd6f4c.0
219d9499.0
23f4c490.0
256fd83b.0
2edf7016.0
2fb1850a.0
31044350.0
33815e15.0
399e7759.0
3ad48a91.0
3c58f906.0
3c860d51.0
3e223c08.0
3e7271e8.0
408e388a.0
412bea73.0
4166ec0c.0
4184de39.0
4643210f.0
46b2fd3b.0
47996b5c.0
4d654d1d.0
4e18c148.0
4fbd6bfa.0
5046c355.0
54edfa5d.0
56b8a0b6.0
56e29e75.0
57692373.0
58a44af1.0
58a44af1.1
594f1775.0
5a3f0ff8.0
5a5372fc.0
5cf9d536.0
5ed36f99.0
635ccfd5.0
69105f4f.0
6adf0799.0
6e52cc39.0
6e8bf996.0
6f5d9899.0
6fcc125d.0
709afd2b.0
72bf6a04.0
72fa7371.0
731f03a5.0
74c26bd0.0
755f7420.0
75680d2e.0
7651b327.0
76579174.0
788c9bfc.0
7999be0d.0
7a819ef2.0
7d3cd826.0
7d453d8f.0
819a45f6.0
81b9768f.0
8317b10c.0
8470719d.0
84cba82f.0
86f32474.0
87753b0d.0
8f7b96c4.0
8fe643df.0
9339512a.0
95750816.0
9772ca32.0
97b4211c.0
9ec3a561.0
a0bc6fbb.0
a145806c.0
a15b3b6b.0
a2df7ad7.0
a3896b44.0
a6776c69.0
a7605362.0
aaa45464.0
ABAecom_=sub.__Am.Bankers_Assn.=_Root_CA.pem
abb5440f
add67345.0
AddTrust_External_Root.pem
AddTrust_Low-Value_Services_Root.pem
AddTrust_Public_Services_Root.pem
AddTrust_Qualified_Certificates_Root.pem
America_Online_Root_Certification_Authority_1.pem
America_Online_Root_Certification_Authority_2.pem
AOL_Time_Warner_Root_Certification_Authority_1.pem
AOL_Time_Warner_Root_Certification_Authority_2.pem
b0f3e76e.0
b3fec4ff.0
b5f329fa.0
b8609e8a.0
Baltimore_CyberTrust_Root.pem
bcdd5959.0
bda4cc84.0
bdacca6f.0
beTRUSTed_Root_CA-Baltimore_Implementation.pem
beTRUSTed_Root_CA
-Entrust_Implementation.pem
beTRUSTed_Root_CA.pem
beTRUSTed_Root_CA
-RSA_Implementation.pem
bf64f35b.0
bf87590f.0
brasil.gov.br.pem
c19d42c7.0
c215bc69.0
c33a80d4.0
c527e4ab.0
c9bc75ba.0
ca-certificates.crt
cacert.org.pem
Camerfirma_Chambers_of_Commerce_Root.pem
Camerfirma_Global_Chambersign_Root.pem
ca.pem
cb796bc1.0
ccb919f9.0
cdaebb72.0
cert_igca_dsa.pem
cert_igca_rsa.pem
Certplus_Class_2_Primary_CA.pem
Certum_Root_CA.pem
cf701eeb.0
class3.pem
Comodo_AAA_Services_root.pem
COMODO_Certification_Authority.pem
Comodo_Secure_Services_root.pem
Comodo_Trusted_Services_root.pem
d2adc77d.0
d537fba6.0
d78a75c7.0
d8274e24.0
ddc328ff.0
deutsche-telekom-root-ca-2.pem
DigiCert_Assured_ID_Root_CA.pem
DigiCert_Global_Root_CA.pem
DigiCert_High_Assurance_EV_Root_CA.pem
Digital_Signature_Trust_Co._Global_CA_1.pem
Digital_Signature_Trust_Co._Global_CA_2.pem
Digital_Signature_Trust_Co._Global_CA_3.pem
Digital_Signature_Trust_Co._Global_CA_4.pem
DST_ACES_CA_X6.pem
DST_Root_CA_X3.pem
e268a4c5.0
e5662767.0
e60bf0c0.0
e775ed2d.0
e7b8d656.0
ed049835.0
ed524cf5.0
ed62f4e3.0
ee7cd6fb.0
Entrust.net_Global_Secure_Personal_CA.pem
Entrust.net_Global_Secure_Server_CA.pem
Entrust.net_Premium_2048_Secure_Server_CA.pem
Entrust.net_Secure_Personal_CA.pem
Entrust.net_Secure_Server_CA.pem
Entrust_Root_Certification_Authority.pem
Equifax_Secure_CA.pem
Equifax_Secure_eBusiness_CA_1.pem
Equifax_Secure_eBusiness_CA_2.pem
Equifax_Secure_Global_eBusiness_CA.pem
f3cf1e8e.0
f4996e82.0
f64d9715.0
f73e89fd.0
f950ccc2.0
facacbc6.0
ff783690.0
Firmaprofesional_Root_CA.pem
GeoTrust_Global_CA_2.pem
GeoTrust_Global_CA.pem
GeoTrust_Primary_Certification_Authority.pem
GeoTrust_Universal_CA_2.pem
GeoTrust_Universal_CA.pem
GlobalSign_Root_CA.pem
GlobalSign_Root_CA
-R2.pem
Go_Daddy_Class_2_CA.pem
GTE_CyberTrust_Global_Root.pem
GTE_CyberTrust_Root_CA.pem
IPS_Chained_CAs_root.pem
IPS_CLASE1_root.pem
IPS_CLASE3_root.pem
IPS_CLASEA1_root.pem
IPS_CLASEA3_root.pem
IPS_Servidores_root.pem
IPS_Timestamping_root.pem
NetLock_Business
=Class_B=Root.pem
NetLock_Express
=Class_C=Root.pem
NetLock_Notary
=Class_A=Root.pem
NetLock_Qualified
=Class_QA=Root.pem
QuoVadis_Root_CA_2.pem
QuoVadis_Root_CA_3.pem
QuoVadis_Root_CA.pem
QuoVadis_Root_Certification_Authority.pem
root.pem
RSA_Root_Certificate_1.pem
RSA_Security_1024_v3.pem
RSA_Security_2048_v3.pem
Secure_Global_CA.pem
SecureTrust_CA.pem
Security_Communication_Root_CA.pem
signet_ca1_pem.pem
signet_ca2_pem.pem
signet_ca3_pem.pem
signet_ocspklasa2_pem.pem
signet_ocspklasa3_pem.pem
signet_pca2_pem.pem
signet_pca3_pem.pem
signet_rootca_pem.pem
signet_tsa1_pem.pem
Sonera_Class_1_Root_CA.pem
Sonera_Class_2_Root_CA.pem
spi-ca-2003.pem
spi-cacert-2008.pem
ssl-cert-snakeoil.pem
Staat_der_Nederlanden_Root_CA.pem
Starfield_Class_2_CA.pem
StartCom_Certification_Authority.pem
StartCom_Ltd..pem
Swisscom_Root_CA_1.pem
SwissSign_Gold_CA
-G2.pem
SwissSign_Platinum_CA
-G2.pem
SwissSign_Silver_CA
-G2.pem
Taiwan_GRCA.pem
TC_TrustCenter__Germany__Class_2_CA.pem
TC_TrustCenter__Germany__Class_3_CA.pem
TDC_Internet_Root_CA.pem
TDC_OCES_Root_CA.pem
Thawte_Personal_Basic_CA.pem
Thawte_Personal_Freemail_CA.pem
Thawte_Personal_Premium_CA.pem
Thawte_Premium_Server_CA.pem
thawte_Primary_Root_CA.pem
Thawte_Server_CA.pem
Thawte_Time_Stamping_CA.pem
TURKTRUST_Certificate_Services_Provider_Root_1.pem
TURKTRUST_Certificate_Services_Provider_Root_2.pem
UTN_DATACorp_SGC_Root_CA.pem
UTN_USERFirst_Email_Root_CA.pem
UTN_USERFirst_Hardware_Root_CA.pem
UTN-USER_First-Network_Applications.pem
UTN_USERFirst_Object_Root_CA.pem
ValiCert_Class_1_VA.pem
ValiCert_Class_2_VA.pem
Verisign_Class_1_Public_Primary_Certification_Authority
-G2.pem
Verisign_Class_1_Public_Primary_Certification_Authority
-G3.pem
Verisign_Class_1_Public_Primary_Certification_Authority.pem
Verisign_Class_2_Public_Primary_Certification_Authority
-G2.pem
Verisign_Class_2_Public_Primary_Certification_Authority
-G3.pem
Verisign_Class_2_Public_Primary_Certification_Authority.pem
Verisign_Class_3_Public_Primary_Certification_Authority
-G2.pem
Verisign_Class_3_Public_Primary_Certification_Authority
-G3.pem
VeriSign_Class_3_Public_Primary_Certification_Authority
-G5.pem
Verisign_Class_3_Public_Primary_Certification_Authority.pem
Verisign_Class_4_Public_Primary_Certification_Authority
-G2.pem
Verisign_Class_4_Public_Primary_Certification_Authority
-_G3.pem
Verisign_RSA_Secure_Server_CA.pem
Verisign_Time_Stamping_Authority_CA.pem
Visa_eCommerce_Root.pem
Visa_International_Global_Root_2.pem
Wells_Fargo_Root_CA.pem
XRamp_Global_CA_Root.pem

Eaven Portillo
Eaven commented April 28, 2011

I'm also trying to implement this fix on heroku...

Here is my setup:

oa-core (0.2.4)
oa-oauth (0.2.4)
  faraday (~> 0.6.1)
  multi_json (>= 0.0.5)
  nokogiri (~> 1.4.2)
  oa-core (= 0.2.4)
  oauth (~> 0.4.0)
  oauth2 (~> 0.4.1)
oauth (0.4.4)
oauth2 (0.4.1)
  faraday (~> 0.6.1)
  multi_json (>= 0.0.5)

I've tried the "fix" in application.rb
require File.expand_path('../boot', FILE)

require 'rails/all'

If you have a Gemfile, require the gems listed there, including any gems

you've limited to :test, :development, or :production.

Bundler.require(:default, Rails.env) if defined?(Bundler)

module Rowingcamps
class Application < Rails::Application
config.middleware.use OmniAuth::Builder do
provider :facebook, FACEBOOK_KEY, FACEBOOK_SECRET, {:client_options => {:ssl => {:ca_path => "/usr/lib/ssl/certs"}}}
end
end
end

Ive also tried sticking it at the bottom of application.rb and its own config/initializers/omniauth.rb as

Rails.application.config.middleware.use OmniAuth::Builder do
provider :facebook, FACEBOOK_KEY, FACEBOOK_SECRET, {:client_options => {:ssl => {:ca_path => "/usr/lib/ssl/certs"}}}
end

It will process to facebook, but on the way back it gives me this error:

2011-04-29T00:49:47+00:00 app[web.1]: RuntimeError (Did not recognize your engine specification. Please specify either a symbol or a class.):

2011-04-29T00:49:46+00:00 app[web.1]: Started GET "/users/auth/facebook/callback?code=ZehYWl7LlGPSmM8CYkFY6_WYlzWkd8P7BlDa8Fbef6g.eyJpdiI6IkUydWpEZUJ5TnpHZjZ3TTFoZ1Zta0EifQ.u1qKg0oqnxLsWZ6ha5JteAApgy0qhutLpkEf_gOZl-Qwy59wmhB3HvtbSs0QAjuiwMJydeSiulwEnfWK8WAKfuKpmVNtfqsENPY8-21UYCMtVlYv8uXuycQ87aXpUFZW" for 67.189.114.129 at Thu Apr 28 17:49:46 -0700 2011
2011-04-29T00:49:47+00:00 app[web.1]:
2011-04-29T00:49:47+00:00 heroku[router]: GET rowing-camps.heroku.com/users/auth/facebook/callback dyno=web.1 queue=0 wait=0ms service=1017ms bytes=934
2011-04-29T00:49:47+00:00 app[web.1]: RuntimeError (Did not recognize your engine specification. Please specify either a symbol or a class.):
2011-04-29T00:49:47+00:00 app[web.1]:

2011-04-29T00:49:47+00:00 app[web.1]:
2011-04-29T00:49:47+00:00 app[web.1]:
2011-04-28T17:49:48-07:00 heroku[nginx]: GET /users/auth/facebook/callback?code=ZehYWl7LlGPSmM8CYkFY6_WYlzWkd8P7BlDa8Fbef6g.eyJpdiI6IkUydWpEZUJ5TnpHZjZ3TTFoZ1Zta0EifQ.u1qKg0oqnxLsWZ6ha5JteAApgy0qhutLpkEf_gOZl-Qwy59wmhB3HvtbSs0QAjuiwMJydeSiulwEnfWK8WAKfuKpmVNtfqsENPY8-21UYCMtVlYv8uXuycQ87aXpUFZW HTTP/1.1 | 67.189.114.129 | 964 | http | 500

Am I doing something wrong?? I've followed the wiki page https://github.com/plataformatec/devise/wiki/OmniAuth:-Overview to the T ;x

Nathalie Ek
nat0 commented April 28, 2011

@eric-hu: you have to change ca_path to ca_file and point it to the ca bundle. So use ca_file instead of ca_path.

Emerson Lackey

Just wanted to let you know that I was having this problem and it was solved by doing what @akremer suggested. I'm using CentOS with Virtualmin and ended up having:

Rails.application.config.middleware.use OmniAuth::Builder do
    provider :facebook, 'secret_key', 'secret_key',
             {:client_options => {:ssl => {:ca_file => '/etc/pki/tls/certs/ca-bundle.crt'}}}
end
eric-hu
eric-hu commented May 02, 2011

@matthiasjakel try using the ca_file option and point it to ca-certificates.crt, with the path included.

dapbot
dapbot commented May 05, 2011

@eric-hu, for the record, I can confirm that pointing to that certificate works on Heroku.

I wasted many hours on a rookie error, though: any permissions must go in the same hash as client_options. For whoever else is trying this, I ended up with:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :facebook, 'YOUR_APP_ID', 'YOUR_SECRET_KEY', 
           {:scope => 'PERMISSION_1, PERMISSION_2, ETC', :client_options => {:ssl => {:ca_file => '/usr/lib/ssl/certs/ca-certificates.crt'}}}
end

I've wasted hours of my life on this that I'll never get back!

eric-hu
eric-hu commented May 06, 2011

@dapbot Thank you for confirming this. I'll add it to the Omniauth wiki so your hours weren't all spent in vain.

What are these permissions used for? I'm wondering if this should go in the Faraday wiki as well

Mislav Marohnić
mislav commented May 06, 2011

@eric-hu: these permissions are for OmniAuth only, so they don't make sense in plain Faraday usage. But other platform-specific information about the location of CA bundles would be a great addition to the Faraday wiki.

dapbot
dapbot commented May 08, 2011

@eric-hu, @mislav, sorry I've been out of town for a few days - but mislav is right: those permissions are Omniauth specific. They are the particular permissions that omniauth requests from facebook when authorising the user.

eric-hu
eric-hu commented May 10, 2011

added this information to the Faraday and Omniauth wikis. Thanks for the confirmations

Rob Whiteston

I have been fighting with this issue on Heroku for several hours now, and I can't get @dapbot's solution to work (unfortunately). I have put in a support request with Heroku. Here is what I am using in my initilizer:

Rails.application.config.middleware.use OmniAuth::Builder do
    provider :facebook, 'MY_APP_ID', 'MY_SECRET', 
    {:scope => 'email, offline_access',:client_options => {:ssl => {:ca_file => '/usr/lib/ssl/certs/ca-certificates.crt'}}}
end

I am doing this through Devise 1.3.4 and Omniauth 0.2.5. I have not tried downgrading Omniauth yet.

dapbot
dapbot commented May 11, 2011

@rwhiten1 I'm using Omniauth 0.2.5 too, so don't know what the difference in our setups could be. I'm not using Devise but don't see how that could matter (?)

Rob Whiteston

@dapbot I was following the devise-omniauth tutorial found here: https://github.com/plataformatec/devise/wiki/OmniAuth:-Overview. Maybe there is some other omniauth configuration parameter I am missing?

f*%$in' clouds. How do they work?

Rob Whiteston

I figured it out. Since I am using Devise, the omniauth config goes into Devise's initializer. So I had erroneously created a brand new initializer for omniauth to handle the SSL issue, but left the omniauth config inside of the Devise initializer. Once I moved the SSL portion into the Devise initializer and removed the separate omniauth initializer file, everything worked!

I am going to document this on the Devise wiki.

xhertz
xhertz commented May 25, 2011

Followed the updated OmniAuth:-Overview tutorial
using devise (1.2.rc) , omniauth (0.2.5), faraday (0.6.1)

I do not have a serparate omniauth initializer file and the /config/initializers/devise.rb contains:
config.omniauth :facebook, "APP_ID", "APP_SECRET",
{:scope => 'email, offline_access', :client_options => {:ssl => {:ca_file => '/usr/lib/ssl/certs/ca-certificates.crt'}}}

Yet I still get the error?
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed):

Ideas?

eric-hu
eric-hu commented May 31, 2011

@xhertz what OS are you using? My first guess would be to eliminate/comment that line and create omniauth.rb in your initializers folder, then put in the following:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :facebook, 'MY_APP_ID', 'MY_SECRET', 
  {:scope => 'email, offline_access',:client_options => {:ssl => {:ca_file => '/usr/lib/ssl/certs/ca-certificates.crt'}}}
end
xhertz
xhertz commented May 31, 2011

Found the problem .... was missing the "," after the 'MY_SECRET' .... darn I make hard mistakes to track down.

Nimble Apps

We plaid for hours with those ca_file and ca_path and cannot manage to make it working with Rails 2.3.8, Ruby 1.8.7...

Here is our configuration :


ActionController::Dispatcher.middleware.use OmniAuth::Builder do
  provider :forcedotcom, SF_APPLICATION_TOKEN, SF_APPLICATION_SECRET,
  {:client_options => {:ssl => {
     :ca_path => '/etc/ssl/certs'
  }}}
end

And the exception that we get is every time looking like this :


Processing SalesforceApisController#blank (for 109.2.237.98 at 2011-06-17 08:36:31) [GET]
  Parameters: {"action"=>"blank", "controller"=>"salesforce_apis", "provider"=>"forcedotcom"}
Completed in 1ms (View: 0, DB: 5) | 404 Not Found [https://ec2-46-137-21-70.eu-west-1.compute.amazonaws.com/auth/forcedotcom]
/!\ FAILSAFE /!\  Fri Jun 17 08:36:32 +0000 2011
  Status: 500 Internal Server Error
  undefined method `closed?' for nil:NilClass
    /usr/local/rvm/rubies/ruby-1.8.7-p249/lib/ruby/1.8/net/http.rb:1060:in `request_without_newrelic_trace'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/newrelic_rpm-3.0.0/lib/new_relic/agent/instrumentation/net.rb:16:in `request'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/newrelic_rpm-3.0.0/lib/new_relic/agent/method_tracer.rb:193:in `trace_execution_scoped'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/newrelic_rpm-3.0.0/lib/new_relic/agent/instrumentation/net.rb:15:in `request'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/faraday-0.6.1/lib/faraday/adapter/net_http.rb:51:in `call'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/faraday-0.6.1/lib/faraday/request/url_encoded.rb:14:in `call'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/faraday-0.6.1/lib/faraday/request.rb:88:in `run'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/faraday-0.6.1/lib/faraday/request.rb:28:in `run'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/faraday-0.6.1/lib/faraday/connection.rb:170:in `run_request'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/oauth2-0.4.1/lib/oauth2/client.rb:63:in `request'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/oauth2-0.4.1/lib/oauth2/strategy/web_server.rb:15:in `get_access_token'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/oa-oauth-0.2.5/lib/omniauth/strategies/oauth2.rb:87:in `build_access_token'
    /usr/local/rvm/gems/ruby-1.8.7-p249/gems/oa-oauth-0.2.5/lib/omniauth/strategies/oauth2.rb:66:in `callback_phase'
    /var/www/devapp/lib/forcedotcom.rb:30:in `callback_phase'

However disabling the cetificate checking with the bellow works fine :


OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE

Here is the content of our /etc/ssl/certs folder :

00673b5b.0 a15b3b6b.0 fb571e3d
02b73561.0 a2df7ad7.0 ff783690.0
0481cb65.0 a3896b44.0 Firmaprofesional_Root_CA.pem
052e396b.0 a6776c69.0 GeoTrust_Global_CA_2.pem
06d75f4b.0 a7405e33.0 GeoTrust_Global_CA.pem
08aef7bb.0 a7605362.0 GeoTrust_Primary_Certification_Authority.pem
0c364b2d.0 aaa45464.0 GeoTrust_Universal_CA_2.pem
0dbd0096.0 ABAecom_=sub.__Am.Bankers_Assn.=_Root_CA.pem GeoTrust_Universal_CA.pem
0e82f83a.0 add67345.0 GlobalSign_Root_CA.pem
10d149a2.0 AddTrust_External_Root.pem GlobalSign_Root_CA
-R2.pem
111e6273.0 AddTrust_Low-Value_Services_Root.pem Go_Daddy_Class_2_CA.pem
1155c94b.0 AddTrust_Public_Services_Root.pem GTE_CyberTrust_Global_Root.pem
11a09b38.0 AddTrust_Qualified_Certificates_Root.pem GTE_CyberTrust_Root_CA.pem
11f154d6.0 America_Online_Root_Certification_Authority_1.pem IPS_Chained_CAs_root.pem
124bbd54.0 America_Online_Root_Certification_Authority_2.pem IPS_CLASE1_root.pem
128b9c8d.0 AOL_Time_Warner_Root_Certification_Authority_1.pem IPS_CLASE3_root.pem
12d55845.0 AOL_Time_Warner_Root_Certification_Authority_2.pem IPS_CLASEA1_root.pem
1689a10b.0 b0f3e76e.0 IPS_CLASEA3_root.pem
17b51fe6.0 b3fec4ff.0 IPS_Servidores_root.pem
19899da5.0 b5f329fa.0 IPS_Timestamping_root.pem
1dac3003.0 b8609e8a.0 NetLock_Business
=Class_B=Root.pem
1dcd6f4c.0 Baltimore_CyberTrust_Root.pem NetLock_Express
=Class_C=Root.pem
219d9499.0 bcdd5959.0 NetLock_Notary
=Class_A=Root.pem
23f4c490.0 bda4cc84.0 NetLock_Qualified
=Class_QA=Root.pem
256fd83b.0 bdacca6f.0 Network_Solutions_Certificate_Authority.pem
2edf7016.0 beTRUSTed_Root_CA-Baltimore_Implementation.pem QuoVadis_Root_CA_2.pem
2fa87019.0 beTRUSTed_Root_CA
-Entrust_Implementation.pem QuoVadis_Root_CA_3.pem
2fb1850a.0 beTRUSTed_Root_CA.pem QuoVadis_Root_CA.pem
31044350.0 beTRUSTed_Root_CA
-RSA_Implementation.pem RSA_Root_Certificate_1.pem
33815e15.0 bf64f35b.0 RSA_Security_1024_v3.pem
399e7759.0 bf87590f.0 RSA_Security_2048_v3.pem
3ad48a91.0 brasil.gov.br.pem Secure_Global_CA.pem
3c58f906.0 c0cafbd2.0 SecureTrust_CA.pem
3c860d51.0 c19d42c7.0 Security_Communication_Root_CA.pem
3e223c08.0 c215bc69.0 signet_ca1_pem.pem
3e7271e8.0 c33a80d4.0 signet_ca2_pem.pem
408e388a.0 c527e4ab.0 signet_ca3_pem.pem
412bea73.0 c9bc75ba.0 signet_ocspklasa2_pem.pem
4166ec0c.0 ca-certificates.crt signet_ocspklasa3_pem.pem
4184de39.0 cacert.org.pem signet_pca2_pem.pem
4643210f.0 Camerfirma_Chambers_of_Commerce_Root.pem signet_pca3_pem.pem
46b2fd3b.0 Camerfirma_Global_Chambersign_Root.pem signet_rootca_pem.pem
47996b5c.0 ca.pem signet_tsa1_pem.pem
4d654d1d.0 cb796bc1.0 Sonera_Class_1_Root_CA.pem
4e18c148.0 cdaebb72.0 Sonera_Class_2_Root_CA.pem
4fbd6bfa.0 cert_igca_dsa.pem spi-ca-2003.pem
5046c355.0 cert_igca_rsa.pem spi-cacert-2008.pem
54edfa5d.0 Certplus_Class_2_Primary_CA.pem ssl-cert-snakeoil.pem
56b8a0b6.0 Certum_Root_CA.pem Staat_der_Nederlanden_Root_CA.pem
56e29e75.0 cf701eeb.0 Starfield_Class_2_CA.pem
57692373.0 Comodo_AAA_Services_root.pem StartCom_Certification_Authority.pem
58a44af1.0 COMODO_Certification_Authority.pem StartCom_Ltd..pem
58a44af1.1 COMODO_ECC_Certification_Authority.pem Swisscom_Root_CA_1.pem
594f1775.0 Comodo_Secure_Services_root.pem SwissSign_Gold_CA
-G2.pem
5a3f0ff8.0 Comodo_Trusted_Services_root.pem SwissSign_Platinum_CA
-G2.pem
5a5372fc.0 d2adc77d.0 SwissSign_Silver_CA
-G2.pem
5cf9d536.0 d537fba6.0 Taiwan_GRCA.pem
5ed36f99.0 d69822e8.0 TC_TrustCenter__Germany__Class_2_CA.pem
635ccfd5.0 d78a75c7.0 TC_TrustCenter__Germany__Class_3_CA.pem
69105f4f.0 d8274e24.0 TDC_Internet_Root_CA.pem
6adf0799.0 ddc328ff.0 TDC_OCES_Root_CA.pem
6e52cc39.0 deutsche-telekom-root-ca-2.pem Thawte_Personal_Basic_CA.pem
6e8bf996.0 DigiCert_Assured_ID_Root_CA.pem Thawte_Personal_Freemail_CA.pem
6f5d9899.0 DigiCert_Global_Root_CA.pem Thawte_Personal_Premium_CA.pem
6fcc125d.0 DigiCert_High_Assurance_EV_Root_CA.pem Thawte_Premium_Server_CA.pem
709afd2b.0 DigiNotar_Root_CA.pem thawte_Primary_Root_CA.pem
72bf6a04.0 Digital_Signature_Trust_Co._Global_CA_1.pem Thawte_Server_CA.pem
72fa7371.0 Digital_Signature_Trust_Co._Global_CA_2.pem Thawte_Time_Stamping_CA.pem
731f03a5.0 Digital_Signature_Trust_Co._Global_CA_3.pem TURKTRUST_Certificate_Services_Provider_Root_1.pem
74c26bd0.0 Digital_Signature_Trust_Co._Global_CA_4.pem TURKTRUST_Certificate_Services_Provider_Root_2.pem
755f7420.0 DST_ACES_CA_X6.pem UTN_DATACorp_SGC_Root_CA.pem
75680d2e.0 DST_Root_CA_X3.pem UTN_USERFirst_Email_Root_CA.pem
7651b327.0 e268a4c5.0 UTN_USERFirst_Hardware_Root_CA.pem
76579174.0 e60bf0c0.0 UTN-USER_First-Network_Applications.pem
788c9bfc.0 e775ed2d.0 ValiCert_Class_1_VA.pem
7999be0d.0 e7b8d656.0 ValiCert_Class_2_VA.pem
7a819ef2.0 ed049835.0 Verisign_Class_1_Public_Primary_Certification_Authority
-G2.pem
7d3cd826.0 ed524cf5.0 Verisign_Class_1_Public_Primary_Certification_Authority
-G3.pem
7d453d8f.0 ed62f4e3.0 Verisign_Class_1_Public_Primary_Certification_Authority.pem
819a45f6.0 ee7cd6fb.0 Verisign_Class_2_Public_Primary_Certification_Authority
-G2.pem
81b9768f.0 Entrust.net_Global_Secure_Personal_CA.pem Verisign_Class_2_Public_Primary_Certification_Authority
-G3.pem
8317b10c.0 Entrust.net_Global_Secure_Server_CA.pem Verisign_Class_2_Public_Primary_Certification_Authority.pem
8470719d.0 Entrust.net_Premium_2048_Secure_Server_CA.pem Verisign_Class_3_Public_Primary_Certification_Authority
-G2.pem
84cba82f.0 Entrust.net_Secure_Personal_CA.pem Verisign_Class_3_Public_Primary_Certification_Authority
-G3.pem
86f32474.0 Entrust.net_Secure_Server_CA.pem VeriSign_Class_3_Public_Primary_Certification_Authority
-G5.pem
87753b0d.0 Entrust_Root_Certification_Authority.pem Verisign_Class_3_Public_Primary_Certification_Authority.pem
89c02a45.0 Equifax_Secure_CA.pem Verisign_Class_4_Public_Primary_Certification_Authority
-G2.pem
8f7b96c4.0 Equifax_Secure_eBusiness_CA_1.pem Verisign_Class_4_Public_Primary_Certification_Authority
-_G3.pem
8fe643df.0 Equifax_Secure_eBusiness_CA_2.pem Verisign_RSA_Secure_Server_CA.pem
9339512a.0 Equifax_Secure_Global_eBusiness_CA.pem Verisign_Time_Stamping_Authority_CA.pem
95750816.0 f3cf1e8e.0 Visa_eCommerce_Root.pem
9772ca32.0 f4996e82.0 Visa_International_Global_Root_2.pem
97b4211c.0 f64d9715.0 Wells_Fargo_Root_CA.pem
9ec3a561.0 f73e89fd.0 WellsSecure_Public_Root_Certificate_Authority.pem
a0bc6fbb.0 f950ccc2.0 XRamp_Global_CA_Root.pem
a145806c.0 facacbc6.0

Thx for your help.

Mislav Marohnić
mislav commented June 18, 2011

@nimbleapps your problem is strange. Even if peer certificates couldn't be verified, an unrelated exception from net/http code shouldn't get raised like in your case. Maybe newrelic screws something up with their hooks.

To all – don't disable peer verification by doing this:

# don't do this!
OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE

Use the :verify option to turn it off:

{ :ssl => { :verify => false } }
Mark W. Foster

@mislav Have used your option to turn off verification after pulling my hair out to get this working. Both,

openssl s_client -CApath etc/ssl/certs -connect graph.facebook.com:443

and

openssl s_client -CAfile etc/ssl/certs/ca-certificates.crt -connect graph.facebook.com:443

Verify return code: 0 (ok)

But, both (devise configuration):

config.omniauth :facebook, 'ID', 'KEY',
{:client_options => {:ssl => {:ca_path => "/etc/ssl/certs"}}}

and

config.omniauth :facebook, 'ID', 'KEY',
{:client_options => {:ssl => {:ca_file => "/etc/ssl/certs/ca-certificates.crt"}}}

return

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

Using: devise (1.3.4) omniauth (0.2.6) faraday (0.6.1) and .crt has read rights for everybody.

Killing me. Any ideas how to chase this down?

Mislav Marohnić
mislav commented June 18, 2011

No idea where your problem lies, @fosrias, but you have perfect conditions to hunt your bug down, given a little extra time. I suggest you set up a small script that accesses Facebook directly through Faraday:

conn = Faraday.new "https://graph.facebook.com", :ssl => { ... }
conn.get "/"

If this request passes, then the problem is some extra library in your app that messes up your HTTP groove. If the request fails, on the other hand, you can dive in more easily with ruby-debug. For assistance I'm available to contact over email – I'd like to get this confusion over soon.

Nimble Apps

@mislav : the problem we had is now solved. We implement a custom strategy and when doing that you need to propagate the parameters provided in the initializer file : this was done with the bellow merge :


module OmniAuth
  module Strategies
    class Forcedotcom  "https://login.salesforce.com",
          :authorize_path => "/services/oauth2/authorize",
          :access_token_path => "/services/oauth2/token"
        }.merge options[:client_options]
        super(app, :forcedotcom, client_id, client_secret, client_options, &block)
      end
    ...
    end
  end
end

anuragphadke19

@mislav : I continue to have this problem inspite of following all the suggestions down to the T.

So, as per the wiki, I have the following in omniauth.rb

Rails.application.config.middleware.use OmniAuth::Builder do
provider :facebook, 'xx', 'xx',
{:client_options => {:ssl => {:ca_path => "/etc/ssl/certs"}}} # Modify this with your SSL certificates path
end

I get the same error.

Then I run the following
irb(main):003:0> conn = Faraday.new "https://graph.facebook.com", :ssl => {:ca_file => "/etc/ssl/certs/ca-bundle.crt"}
=> #"/etc/ssl/certs/ca-bundle.crt"}, @path_prefix="/", @options={}, @params={}, @builder=#, @port=nil, @scheme="https", @headers={}, @host="graph.facebook.com", @parallel_manager=nil>
irb(main):004:0> conn.get "/"
=> #302, :url=>#, :method=>:get, :response=>#, :ssl=>{:ca_file=>"/etc/ssl/certs/ca-bundle.crt"}, :parallel_manager=>nil, :request_headers=>{}, :request=>{:proxy=>nil}, :response_headers=>{"location"=>"http://developers.facebook.com/docs/api", "expires"=>"Sat, 01 Jan 2000 00:00:00 GMT", "content-type"=>"text/html; charset=utf-8", "connection"=>"close", "date"=>"Mon, 03 Oct 2011 15:33:06 GMT", "content-length"=>"0", "cache-control"=>"private, no-cache, no-store, must-revalidate", "x-fb-rev"=>"452062", "x-fb-server"=>"10.64.36.62", "pragma"=>"no-cache"}, :body=>""}>

so it works using faraday. Do you think omniauth is rejecting the ssl?

Mislav Marohnić

@anuragphadke19: With OmniAuth, you used :ca_path. With Faraday directly you used :ca_file and it worked. So, go back to using OmniAuth and use :ca_file instead of :ca_path.

anuragphadke19

Doesn't help.

Rails.application.config.middleware.use OmniAuth::Builder do
provider :facebook, 'xxxx', 'xxx',
{:client_options => {:ssl => {:ca_file => "/etc/ssl/certs/ca-bundle.crt"}}} # Modify this with your SSL certificates path
end

eric-hu

@anuragphadke19 I saw that exact error (even with FB auth) recently using the most recent version of OmniAuth. I solved the issue by reverting to 0.2.6.

Since Omniauth is moving all of the strategies (like Facebook) to other gems, I'm sticking with a slightly older version for now.

anuragphadke19

@eric-hu : I downgraded omniauth but it still doesn't help. Here are the versions for the relevant gems:

faraday - 0.6.1
omniauth - 0.2.6
oauth - 0.4.5
oauth2 - 0.4.1

The thing thats bugging me is, how come it works on my development OS X machine and doesn't work on the Production Linux box. BTW, I am using the EC2 Linux AMI as production box. Any other ideas to resolve this are most welcome at this point.

eric-hu

@anuragphadke19 ah ok, if it work on OS X, this isn't the same bug I was seeing.

Are your certs on the EC2 Linux AMI valid? (Did you run the Faraday test code above on the EC2 AMI)
Is your cert path accessible as a non-root user?

If those both check out, can you see if the code works with your application running in production mode on your OS X machine? That might help to narrow this problem down.

anuragphadke19

@eric-hu : I tried your suggestion of running my application in production mode on my OS X development machine and it works there. In fact I don't even need the omniauth.rb "fix" to make it work there.

About the other 2 things that you asked:

I ran the Farady code on my production box.
And the EC2 linux AMI cert is valid and has world read access.

Any other insights?

eric-hu

I'm not too familiar with the EC2 linux AMIs. Can you shell into them to run IRB? If so, I would try that next and check your Faraday code.

Is everything else identical between your OS X dev machine and EC2? Ruby engine, bundle list? I'm starting to grasp at straws, so if anyone else has ideas...

Yavor Ivanov

I stumbled upon this problem for a second time now.
This time nothing worked. Only Mislav's solution worked.
Problem for me occurred on a Rails 2.3.12 app when upgrading all the dependent gems.

And the solution also worked on all other apps we have including Rails 3.x

{ :ssl => { :verify => false } }

Thanks!

Sean McCleary

If you use macs and linux for development or for production you might need to dynamically determine the certificate path of the machine. I did this.

    auth_config = YAML.load(File.read(Rails.root.to_s + '/config/omniauth.yml'))
    cert_path = `openssl version -a`.match(%r~.*OPENSSLDIR: ("[a-zA-Z\/]+")~)[1] 
    config.omniauth :facebook, auth_config[Rails.env]['facebook']['app_id'], auth_config[Rails.env]['facebook']['secret'], :client_options => {:ssl => {:ca_path => cert_path}}
    config.omniauth :google_oauth2, auth_config[Rails.env]['google']['app_id'], auth_config[Rails.env]['google']['secret'], :client_options => {:ssl => {:ca_path => cert_path}}
Pankaj Tyagi

BTW if you are having the similar issue with jruby download cacert.pem and put this in config/initializers

#
# File: cacert_openssl_hack.rb
# Dir : config/initializers
#
# open ssl in jruby cannot use JVM trust anchor to get CA certificates.  So I am bundeling 
# the CA certs in lib/ssl/certs/cacert.pem and telling open ssl to use it but only if running 
# as jruby.
# The ca certs were down loaded using curl -O http://curl.haxx.se/ca/cacert.pem
#

ENV["SSL_CERT_FILE"]=Rails.root.join("lib/ssl/certs/cacert.pem").to_s if RUBY_ENGINE == "jruby"
Ethos

For those arriving via Google, I had this issue in OS X with the system version of openssl: OpenSSL 0.9.8r 8 Feb 2011
Rather than specify a cert directory, I used rvm to update openssl to 1.0.1c and rebuild my rubies against them:

rvm pkg install openssl
rvm reinstall 1.9.3 --force

This fixed my problem without needing to specify certs. A similar solution with brew might work as well.

dchersey

For those developing on OS/X, it seems the easiest solution is to disable certificate verification for OpenSSL.
Be SURE you only do this in development!

Just put this code in your devise initializer before the config.omniauth:
OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE if Rails.env.development?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.