[chef] Re: Re: Re: Re: Excon::Errors::SocketError Unable to verify certificate


Chronological Thread 
  • From: Lamont Granquist < >
  • To: < >
  • Subject: [chef] Re: Re: Re: Re: Excon::Errors::SocketError Unable to verify certificate
  • Date: Fri, 21 Jun 2013 14:44:27 -0700


Yes, plz to be opening bug.  =)

I'm not certain that is the right solution, we might be able to fix ssl_context.cert_store.set_default_paths as used by excon to DTRT which may be more correct, but that'll take more research...

On 6/21/13 2:41 PM, "> wrote:
" type="cite">
On Fri, 21 Jun 2013, Lamont Granquist wrote:

It looks like excon is now searching for an openssl.cnf, and omnibus
ships with the example openssl.cnf which openssl installs by default
in the omnibus build at /opt/chef/embedded/ssl/openssl.cnf -- and
when it finds that file it goes off and does something using
incorrect information that isn't entirely clear to me...

Since the start of openssl.cnf begins with a comment about "This is
mostly being used for generation of certificate requests." it isn't
clear to me why a client app expects to get something useful out of
that.  But it also isn't clear to me why openssl isn't installing
that as openssl.cnf.example or something.

AFAIK, we could remove that out of the omnibus build and then I
think it will fall back to the DEFAULT_CA_FILE in the omnibus build
correctly...

If you manually nuke that file does excon 0.25.0 work correctly?

Yep! That allowed a successful run with excon 0.25.0.

Should I open a bug with all of this info?


 
On 6/21/13 12:50 PM, 
 
 ">
  wrote:
On Fri, 21 Jun 2013, 
 
 ">
  wrote:

My newly launched nodes started failing in their route53 recipe last nite with
this error:

FATAL: Excon::Errors::SocketError:
route53_record[chef-ci-web.dev.needtogetmyoontzon.com]
(resolver::default line 128) had an error: Excon::Errors::SocketError:
Unable to verify certificate, please set `Excon.defaults[:ssl_ca_path]
= path_to_certs`, `Excon.defaults[:ssl_ca_file] = path_to_file`, or
`Excon.defaults[:ssl_verify_peer] = false` (less secure).

On such a system, I see:

/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/excon-0.25.0

On a system launched only a couple days ago, I see

/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/excon-0.24.0

I see 0.25.0 changed the behavior of how it finds certs:
https://github.com/geemus/excon/blob/master/changelog.txt

I'm not sure if I should bug geemus, or the chef community. In the meantime,
I'm gonna see if I can pin my clients to 0.24.0 so we're not stuck on this.
I was able to prevent excon 0.25.0 from being installed, and instead install
excon 0.24.0 by calling this early in my run_list:

    chef_gem "excon" do
      version "0.24.0"
    end

fwiw.

My deets:

AWS Linux 2012.09, chef 10.24.0





Archive powered by MHonArc 2.6.16.

§