Excon::Errors::SocketError Unable to verify certificate


#1

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:

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.

kallen


#2

On Fri, 21 Jun 2013, kallen@groknaut.net 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


#3

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?

On 6/21/13 12:50 PM, kallen@groknaut.net wrote:

On Fri, 21 Jun 2013, kallen@groknaut.net 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


#4

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, kallen@groknaut.net wrote:

On Fri, 21 Jun 2013, kallen@groknaut.net 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


#5

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, kallen@groknaut.net 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, kallen@groknaut.net wrote:

On Fri, 21 Jun 2013, kallen@groknaut.net 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


#6

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, kallen@groknaut.net 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, kallen@groknaut.net wrote:

On Fri, 21 Jun 2013, kallen@groknaut.net 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