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