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


Chronological Thread 
  • From:
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Excon::Errors::SocketError Unable to verify certificate
  • Date: Fri, 21 Jun 2013 21:58:17 +0000


Done. Thanks Lamont!

http://tickets.opscode.com/browse/CHEF-4309


On Fri, 21 Jun 2013, Lamont Granquist wrote:

> 
> 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:
> >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.

§