I just had an 'aha' moment when trying to make the PMT tool interact
with the forge using SSL.
The problem is with Ruby & OpenSSL and its need for a CA path or file
when I want to use VERIFY_PEER as a mechanism. Since
forge.puppetlabs.com uses a publicly signed certificate, I need to
provide the public CA.
I've managed to solve it on Linux by specifying:
https_object.ca_path = '/etc/ssl/certs'
But this isn't going to cut it cross-platform. I'm thinking there is
at least two viable solutions:
a) We hunt around a users OS looking for the cert directories, since
this is going to be prone to problems, we'd need to deal with edge
cases and possibly provide a knob or fallback behaviour for this
b) We ship our own lists of CA's. Its not enough to just ship only our
CA (GeoTrust) as they might be out of business one day, and we'll have
to deal with that. We'd probably need to ship a larger amount, like
the full list provided by curl or something. This would be something
we would continue to maintain and update indefinitely as well (so when
CA's get revoked, we would have to revoke as well).
Does anyone have any other ideas around a solution to this problem? Or
perhaps a viable alternative? Any help would be greatly appreciated.
>>> I've managed to solve it on Linux by specifying:
>>> https_object.ca_path = '/etc/ssl/certs'
> You managed to work around your broken build, I think.
You mean Debian 6's broken build - Lol ... found this using the system
ruby 1.8 from Debian, latest version :-).
> We should use the system certificate set, and *ONLY* the system
> certificate set, since that is the only that that will allow our users
> control over what is or is not trusted.
> Anything where we adjust the default settings is a terrible mistake:
> we are taking out of the hands of our users the right to manage trust.
> (With the obvious exception of our own private CA for internal use. :)
Sure - good point.
> On Linux that usually means installing `ca-certificates` or a
> similarly named package. On the mac, with the system OpenSSL, that
> comes from KeyChain. On Windows I don't actually know, but I would
> expect it to integrate with the system trust store.
> The most common place I have run into this with is RVM, either using a
> non-standard OpenSSL (eg: RVM package, or MacPorts), in which case the
> solution is to configure your other OpenSSL correctly also.
Sounds like I'll have to go through the various system Rubies and SSL
variants and found out how broken or weird they are, and find out what
is needed to make them work.
What is actually interesting about this topic is that the two common
command line tools for web access uses different methodologies. Curl
uses its own CA's, and wget uses the in-built OpenSSL list it seems.
I had a quick look at other Ruby tools to see what they do ... Octokit
turns off verify ... which is quite sad really, but I imagine this is
due to the hassles involved in making this work properly. I don't want
to take this route.
On Mon, Jun 25, 2012 at 1:11 PM, Ken Barber <k...@puppetlabs.com> wrote:
> (responding to puppet-dev)
>>>> I've managed to solve it on Linux by specifying:
>>>> https_object.ca_path = '/etc/ssl/certs'
>> You managed to work around your broken build, I think.
> You mean Debian 6's broken build - Lol ... found this using the system
> ruby 1.8 from Debian, latest version :-).
>> We should use the system certificate set, and *ONLY* the system
>> certificate set, since that is the only that that will allow our users
>> control over what is or is not trusted.
>> Anything where we adjust the default settings is a terrible mistake:
>> we are taking out of the hands of our users the right to manage trust.
>> (With the obvious exception of our own private CA for internal use. :)
> Sure - good point.
>> On Linux that usually means installing `ca-certificates` or a
>> similarly named package. On the mac, with the system OpenSSL, that
>> comes from KeyChain. On Windows I don't actually know, but I would
>> expect it to integrate with the system trust store.
>> The most common place I have run into this with is RVM, either using a
>> non-standard OpenSSL (eg: RVM package, or MacPorts), in which case the
>> solution is to configure your other OpenSSL correctly also.
> Sounds like I'll have to go through the various system Rubies and SSL
> variants and found out how broken or weird they are, and find out what
> is needed to make them work.
On Mon, Jun 25, 2012 at 5:23 AM, Ken Barber <k...@puppetlabs.com> wrote:
> What is actually interesting about this topic is that the two common
> command line tools for web access uses different methodologies. Curl
> uses its own CA's, and wget uses the in-built OpenSSL list it seems.
Curl on OS X at least used to use the system keychain (built-in
version, not compiled versions from MacPorts etc)
> I had a quick look at other Ruby tools to see what they do ... Octokit
> turns off verify ... which is quite sad really, but I imagine this is
> due to the hassles involved in making this work properly. I don't want
> to take this route.
I very much don't want us to be distributing another bundle of certs.
When you're trying to maintain a tightly curated set of trusted root
certs, chasing down individual application cert bundles is immensely
frustrating.
On Mon, Jun 25, 2012 at 5:11 AM, Ken Barber <k...@puppetlabs.com> wrote:
> (responding to puppet-dev)
>>>> I've managed to solve it on Linux by specifying:
>>>> https_object.ca_path = '/etc/ssl/certs'
>> You managed to work around your broken build, I think.
> You mean Debian 6's broken build - Lol ... found this using the system
> ruby 1.8 from Debian, latest version :-).
Did you install the `ca-certificates` package? I never had any
problem with this on Debian, although they might have broken Ruby.
You should report it as an upstream bug if they have. :)
-- Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons
On Mon, Jun 25, 2012 at 5:11 AM, Ken Barber <k...@puppetlabs.com> wrote:
> (responding to puppet-dev)
> >>> I've managed to solve it on Linux by specifying:
> >>> https_object.ca_path = '/etc/ssl/certs'
> > You managed to work around your broken build, I think.
> You mean Debian 6's broken build - Lol ... found this using the system
> ruby 1.8 from Debian, latest version :-).
> > We should use the system certificate set, and *ONLY* the system
> > certificate set, since that is the only that that will allow our users
> > control over what is or is not trusted.
> > Anything where we adjust the default settings is a terrible mistake:
> > we are taking out of the hands of our users the right to manage trust.
> > (With the obvious exception of our own private CA for internal use. :)
> Sure - good point.
> > On Linux that usually means installing `ca-certificates` or a
> > similarly named package. On the mac, with the system OpenSSL, that
> > comes from KeyChain. On Windows I don't actually know, but I would
> > expect it to integrate with the system trust store.
> > The most common place I have run into this with is RVM, either using a
> > non-standard OpenSSL (eg: RVM package, or MacPorts), in which case the
> > solution is to configure your other OpenSSL correctly also.
> Sounds like I'll have to go through the various system Rubies and SSL
> variants and found out how broken or weird they are, and find out what
> is needed to make them work.
I think you just want to call X509_STORE_set_default_paths[1], which will
load the ca certs from the platform-appropriate trust store. There seems to
be a ruby method for it[2]
As far as Windows, there's an openssl patch to have it use capi (crypto
api) to load the trusted certs[3].
On Mon, Jun 25, 2012 at 9:54 AM, Josh Cooper <j...@puppetlabs.com> wrote:
> On Mon, Jun 25, 2012 at 5:11 AM, Ken Barber <k...@puppetlabs.com> wrote:
>> (responding to puppet-dev)
>> >>> I've managed to solve it on Linux by specifying:
>> >>> https_object.ca_path = '/etc/ssl/certs'
>> > You managed to work around your broken build, I think.
>> You mean Debian 6's broken build - Lol ... found this using the system
>> ruby 1.8 from Debian, latest version :-).
>> > We should use the system certificate set, and *ONLY* the system
>> > certificate set, since that is the only that that will allow our users
>> > control over what is or is not trusted.
>> > Anything where we adjust the default settings is a terrible mistake:
>> > we are taking out of the hands of our users the right to manage trust.
>> > (With the obvious exception of our own private CA for internal use. :)
>> Sure - good point.
>> > On Linux that usually means installing `ca-certificates` or a
>> > similarly named package. On the mac, with the system OpenSSL, that
>> > comes from KeyChain. On Windows I don't actually know, but I would
>> > expect it to integrate with the system trust store.
>> > The most common place I have run into this with is RVM, either using a
>> > non-standard OpenSSL (eg: RVM package, or MacPorts), in which case the
>> > solution is to configure your other OpenSSL correctly also.
>> Sounds like I'll have to go through the various system Rubies and SSL
>> variants and found out how broken or weird they are, and find out what
>> is needed to make them work.
> I think you just want to call X509_STORE_set_default_paths[1], which will
> load the ca certs from the platform-appropriate trust store. There seems to
> be a ruby method for it[2]
That would be great to test - it shouldn't be necessary, since Ruby
OpenSSL should do that by default, but if it fixes Ken's problem we
might have some other latent ... dunno. Oddity. Change in semantics
between Ruby versions. Something stupid like that.
Generally, though, you don't need to *do* anything to get Ruby OpenSSL
to validate commercial certificates.
-- Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons
OpenBSD 4.9:
ca_file = /etc/ssl/cert.pem # doesn't contain GeoTrust, so doesn't work for me
DragonFly BSD:
?? couldn't find it, need more time I presume
SLES 11:
ca_path = /etc/ssl/certs
Solaris 10:
ca_path = /opt/csw/etc/ssl/certs # not very good, as its CSW specific
ca_path = /etc/sfw/openssl/certs/ # is empty ... so I couldn't find
anything in core?
Solars 11:
ca_path = /opt/csw/etc/ssl/certs # not very good, as its CSW specific
ca_path = /etc/sfw/openssl/certs/ # no longer empty, but not the CA's we need
In all cases I had to set something in core with Ruby 1.8.7 btw. The
only case where it 'just worked' was in RVM Ruby 1.8.7 on my Mac. Ruby
1.9.3 with RVM didn't work, probably due to OpenSSL oddities.
I'm looking into Josh's pointers, seems like this should be working I
agree, or the path should be built in somehow somewhere. Here is the
sample stub code I've been testing with so far FWIW:
On Mon, Jun 25, 2012 at 5:58 PM, Daniel Pittman <dan...@puppetlabs.com> wrote:
> On Mon, Jun 25, 2012 at 9:54 AM, Josh Cooper <j...@puppetlabs.com> wrote:
>> On Mon, Jun 25, 2012 at 5:11 AM, Ken Barber <k...@puppetlabs.com> wrote:
>>> (responding to puppet-dev)
>>> >>> I've managed to solve it on Linux by specifying:
>>> >>> https_object.ca_path = '/etc/ssl/certs'
>>> > You managed to work around your broken build, I think.
>>> You mean Debian 6's broken build - Lol ... found this using the system
>>> ruby 1.8 from Debian, latest version :-).
>>> > We should use the system certificate set, and *ONLY* the system
>>> > certificate set, since that is the only that that will allow our users
>>> > control over what is or is not trusted.
>>> > Anything where we adjust the default settings is a terrible mistake:
>>> > we are taking out of the hands of our users the right to manage trust.
>>> > (With the obvious exception of our own private CA for internal use. :)
>>> Sure - good point.
>>> > On Linux that usually means installing `ca-certificates` or a
>>> > similarly named package. On the mac, with the system OpenSSL, that
>>> > comes from KeyChain. On Windows I don't actually know, but I would
>>> > expect it to integrate with the system trust store.
>>> > The most common place I have run into this with is RVM, either using a
>>> > non-standard OpenSSL (eg: RVM package, or MacPorts), in which case the
>>> > solution is to configure your other OpenSSL correctly also.
>>> Sounds like I'll have to go through the various system Rubies and SSL
>>> variants and found out how broken or weird they are, and find out what
>>> is needed to make them work.
>> I think you just want to call X509_STORE_set_default_paths[1], which will
>> load the ca certs from the platform-appropriate trust store. There seems to
>> be a ruby method for it[2]
> That would be great to test - it shouldn't be necessary, since Ruby
> OpenSSL should do that by default, but if it fixes Ken's problem we
> might have some other latent ... dunno. Oddity. Change in semantics
> between Ruby versions. Something stupid like that.
> Generally, though, you don't need to *do* anything to get Ruby OpenSSL
> to validate commercial certificates.
> --
> Daniel Pittman
> ⎋ Puppet Labs Developer – http://puppetlabs.com > ♲ Made with 100 percent post-consumer electrons
> --
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to puppet-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
On Mon, Jun 25, 2012 at 6:06 PM, Ken Barber <k...@puppetlabs.com> wrote:
> Well, I've done an OS survey and found the following paths need to be
> set, and in some cases couldn't find a path at all:
> OpenBSD 4.9:
> ca_file = /etc/ssl/cert.pem # doesn't contain GeoTrust, so doesn't work for me
> DragonFly BSD:
> ?? couldn't find it, need more time I presume
> SLES 11:
> ca_path = /etc/ssl/certs
> Solaris 10:
> ca_path = /opt/csw/etc/ssl/certs # not very good, as its CSW specific
> ca_path = /etc/sfw/openssl/certs/ # is empty ... so I couldn't find
> anything in core?
> Solars 11:
> ca_path = /opt/csw/etc/ssl/certs # not very good, as its CSW specific
> ca_path = /etc/sfw/openssl/certs/ # no longer empty, but not the CA's we need
> In all cases I had to set something in core with Ruby 1.8.7 btw. The
> only case where it 'just worked' was in RVM Ruby 1.8.7 on my Mac. Ruby
> 1.9.3 with RVM didn't work, probably due to OpenSSL oddities.
> I'm looking into Josh's pointers, seems like this should be working I
> agree, or the path should be built in somehow somewhere. Here is the
> sample stub code I've been testing with so far FWIW:
> response = nil
> proxy.start do |http|
> request = Net::HTTP::Get.new('/')
> response = http.request(request)
> end
> puts response.body
> ken.
> On Mon, Jun 25, 2012 at 5:58 PM, Daniel Pittman <dan...@puppetlabs.com> wrote:
>> On Mon, Jun 25, 2012 at 9:54 AM, Josh Cooper <j...@puppetlabs.com> wrote:
>>> On Mon, Jun 25, 2012 at 5:11 AM, Ken Barber <k...@puppetlabs.com> wrote:
>>>> (responding to puppet-dev)
>>>> >>> I've managed to solve it on Linux by specifying:
>>>> >>> https_object.ca_path = '/etc/ssl/certs'
>>>> > You managed to work around your broken build, I think.
>>>> You mean Debian 6's broken build - Lol ... found this using the system
>>>> ruby 1.8 from Debian, latest version :-).
>>>> > We should use the system certificate set, and *ONLY* the system
>>>> > certificate set, since that is the only that that will allow our users
>>>> > control over what is or is not trusted.
>>>> > Anything where we adjust the default settings is a terrible mistake:
>>>> > we are taking out of the hands of our users the right to manage trust.
>>>> > (With the obvious exception of our own private CA for internal use. :)
>>>> Sure - good point.
>>>> > On Linux that usually means installing `ca-certificates` or a
>>>> > similarly named package. On the mac, with the system OpenSSL, that
>>>> > comes from KeyChain. On Windows I don't actually know, but I would
>>>> > expect it to integrate with the system trust store.
>>>> > The most common place I have run into this with is RVM, either using a
>>>> > non-standard OpenSSL (eg: RVM package, or MacPorts), in which case the
>>>> > solution is to configure your other OpenSSL correctly also.
>>>> Sounds like I'll have to go through the various system Rubies and SSL
>>>> variants and found out how broken or weird they are, and find out what
>>>> is needed to make them work.
>>> I think you just want to call X509_STORE_set_default_paths[1], which will
>>> load the ca certs from the platform-appropriate trust store. There seems to
>>> be a ruby method for it[2]
>> That would be great to test - it shouldn't be necessary, since Ruby
>> OpenSSL should do that by default, but if it fixes Ken's problem we
>> might have some other latent ... dunno. Oddity. Change in semantics
>> between Ruby versions. Something stupid like that.
>> Generally, though, you don't need to *do* anything to get Ruby OpenSSL
>> to validate commercial certificates.
>> --
>> Daniel Pittman
>> ⎋ Puppet Labs Developer – http://puppetlabs.com >> ♲ Made with 100 percent post-consumer electrons
>> --
>> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
>> To post to this group, send email to puppet-dev@googlegroups.com.
>> To unsubscribe from this group, send email to puppet-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
> ctx = OpenSSL::SSL::SSLContext.new
> ctx.verify_mode = OpenSSL::SSL::VERIFY_PEER
> # Comment this out, it breaks
> ctx.cert_store = cert_store
> s = TCPSocket.open('forge.puppetlabs.com', '443')
> s = OpenSSL::SSL::SSLSocket.new(s, ctx)
> s.sync_close = true
> s.connect
> Before I had to use ctx.ca_path = '/etc/ssl/certs'. I think we are on
> to something here.
> ken.
> On Mon, Jun 25, 2012 at 6:06 PM, Ken Barber <k...@puppetlabs.com> wrote:
>> Well, I've done an OS survey and found the following paths need to be
>> set, and in some cases couldn't find a path at all:
>> OpenBSD 4.9:
>> ca_file = /etc/ssl/cert.pem # doesn't contain GeoTrust, so doesn't work for me
>> DragonFly BSD:
>> ?? couldn't find it, need more time I presume
>> SLES 11:
>> ca_path = /etc/ssl/certs
>> Solaris 10:
>> ca_path = /opt/csw/etc/ssl/certs # not very good, as its CSW specific
>> ca_path = /etc/sfw/openssl/certs/ # is empty ... so I couldn't find
>> anything in core?
>> Solars 11:
>> ca_path = /opt/csw/etc/ssl/certs # not very good, as its CSW specific
>> ca_path = /etc/sfw/openssl/certs/ # no longer empty, but not the CA's we need
>> In all cases I had to set something in core with Ruby 1.8.7 btw. The
>> only case where it 'just worked' was in RVM Ruby 1.8.7 on my Mac. Ruby
>> 1.9.3 with RVM didn't work, probably due to OpenSSL oddities.
>> I'm looking into Josh's pointers, seems like this should be working I
>> agree, or the path should be built in somehow somewhere. Here is the
>> sample stub code I've been testing with so far FWIW:
>> response = nil
>> proxy.start do |http|
>> request = Net::HTTP::Get.new('/')
>> response = http.request(request)
>> end
>> puts response.body
>> ken.
>> On Mon, Jun 25, 2012 at 5:58 PM, Daniel Pittman <dan...@puppetlabs.com> wrote:
>>> On Mon, Jun 25, 2012 at 9:54 AM, Josh Cooper <j...@puppetlabs.com> wrote:
>>>> On Mon, Jun 25, 2012 at 5:11 AM, Ken Barber <k...@puppetlabs.com> wrote:
>>>>> (responding to puppet-dev)
>>>>> >>> I've managed to solve it on Linux by specifying:
>>>>> >>> https_object.ca_path = '/etc/ssl/certs'
>>>>> > You managed to work around your broken build, I think.
>>>>> You mean Debian 6's broken build - Lol ... found this using the system
>>>>> ruby 1.8 from Debian, latest version :-).
>>>>> > We should use the system certificate set, and *ONLY* the system
>>>>> > certificate set, since that is the only that that will allow our users
>>>>> > control over what is or is not trusted.
>>>>> > Anything where we adjust the default settings is a terrible mistake:
>>>>> > we are taking out of the hands of our users the right to manage trust.
>>>>> > (With the obvious exception of our own private CA for internal use. :)
>>>>> Sure - good point.
>>>>> > On Linux that usually means installing `ca-certificates` or a
>>>>> > similarly named package. On the mac, with the system OpenSSL, that
>>>>> > comes from KeyChain. On Windows I don't actually know, but I would
>>>>> > expect it to integrate with the system trust store.
>>>>> > The most common place I have run into this with is RVM, either using a
>>>>> > non-standard OpenSSL (eg: RVM package, or MacPorts), in which case the
>>>>> > solution is to configure your other OpenSSL correctly also.
>>>>> Sounds like I'll have to go through the various system Rubies and SSL
>>>>> variants and found out how broken or weird they are, and find out what
>>>>> is needed to make them work.
>>>> I think you just want to call X509_STORE_set_default_paths[1], which will
>>>> load the ca certs from the platform-appropriate trust store. There seems to
>>>> be a ruby method for it[2]
>>> That would be great to test - it shouldn't be necessary, since Ruby
>>> OpenSSL should do that by default, but if it fixes Ken's problem we
>>> might have some other latent ... dunno. Oddity. Change in semantics
>>> between Ruby versions. Something stupid like that.
>>> Generally, though, you don't need to *do* anything to get Ruby OpenSSL
>>> to validate commercial certificates.
>>> --
>>> Daniel Pittman
>>> ⎋ Puppet Labs Developer – http://puppetlabs.com >>> ♲ Made with 100 percent post-consumer electrons
>>> --
>>> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
>>> To post to this group, send email to puppet-dev@googlegroups.com.
>>> To unsubscribe from this group, send email to puppet-dev+unsubscribe@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
I think the general problem here is the lack of a default SSL path on
some platforms, which is either an upstream problem - or some package
I'm lacking (my BSD foo isn't great). This is however a good starting
point and feels like the 'right thing to do'. I'll keep working on the
details of those non-working platforms. Thanks a lot Josh & Daniel for
your help.
>> ctx = OpenSSL::SSL::SSLContext.new
>> ctx.verify_mode = OpenSSL::SSL::VERIFY_PEER
>> # Comment this out, it breaks
>> ctx.cert_store = cert_store
>> s = TCPSocket.open('forge.puppetlabs.com', '443')
>> s = OpenSSL::SSL::SSLSocket.new(s, ctx)
>> s.sync_close = true
>> s.connect
>> Before I had to use ctx.ca_path = '/etc/ssl/certs'. I think we are on
>> to something here.
>> ken.
>> On Mon, Jun 25, 2012 at 6:06 PM, Ken Barber <k...@puppetlabs.com> wrote:
>>> Well, I've done an OS survey and found the following paths need to be
>>> set, and in some cases couldn't find a path at all:
>>> OpenBSD 4.9:
>>> ca_file = /etc/ssl/cert.pem # doesn't contain GeoTrust, so doesn't work for me
>>> DragonFly BSD:
>>> ?? couldn't find it, need more time I presume
>>> SLES 11:
>>> ca_path = /etc/ssl/certs
>>> Solaris 10:
>>> ca_path = /opt/csw/etc/ssl/certs # not very good, as its CSW specific
>>> ca_path = /etc/sfw/openssl/certs/ # is empty ... so I couldn't find
>>> anything in core?
>>> Solars 11:
>>> ca_path = /opt/csw/etc/ssl/certs # not very good, as its CSW specific
>>> ca_path = /etc/sfw/openssl/certs/ # no longer empty, but not the CA's we need
>>> In all cases I had to set something in core with Ruby 1.8.7 btw. The
>>> only case where it 'just worked' was in RVM Ruby 1.8.7 on my Mac. Ruby
>>> 1.9.3 with RVM didn't work, probably due to OpenSSL oddities.
>>> I'm looking into Josh's pointers, seems like this should be working I
>>> agree, or the path should be built in somehow somewhere. Here is the
>>> sample stub code I've been testing with so far FWIW:
>>> response = nil
>>> proxy.start do |http|
>>> request = Net::HTTP::Get.new('/')
>>> response = http.request(request)
>>> end
>>> puts response.body
>>> ken.
>>> On Mon, Jun 25, 2012 at 5:58 PM, Daniel Pittman <dan...@puppetlabs.com> wrote:
>>>> On Mon, Jun 25, 2012 at 9:54 AM, Josh Cooper <j...@puppetlabs.com> wrote:
>>>>> On Mon, Jun 25, 2012 at 5:11 AM, Ken Barber <k...@puppetlabs.com> wrote:
>>>>>> (responding to puppet-dev)
>>>>>> >>> I've managed to solve it on Linux by specifying:
>>>>>> >>> https_object.ca_path = '/etc/ssl/certs'
>>>>>> > You managed to work around your broken build, I think.
>>>>>> You mean Debian 6's broken build - Lol ... found this using the system
>>>>>> ruby 1.8 from Debian, latest version :-).
>>>>>> > We should use the system certificate set, and *ONLY* the system
>>>>>> > certificate set, since that is the only that that will allow our users
>>>>>> > control over what is or is not trusted.
>>>>>> > Anything where we adjust the default settings is a terrible mistake:
>>>>>> > we are taking out of the hands of our users the right to manage trust.
>>>>>> > (With the obvious exception of our own private CA for internal use. :)
>>>>>> Sure - good point.
>>>>>> > On Linux that usually means installing `ca-certificates` or a
>>>>>> > similarly named package. On the mac, with the system OpenSSL, that
>>>>>> > comes from KeyChain. On Windows I don't actually know, but I would
>>>>>> > expect it to integrate with the system trust store.
>>>>>> > The most common place I have run into this with is RVM, either using a
>>>>>> > non-standard OpenSSL (eg: RVM package, or MacPorts), in which case the
>>>>>> > solution is to configure your other OpenSSL correctly also.
>>>>>> Sounds like I'll have to go through the various system Rubies and SSL
>>>>>> variants and found out how broken or weird they are, and find out what
>>>>>> is needed to make them work.
>>>>> I think you just want to call X509_STORE_set_default_paths[1], which will
>>>>> load the ca certs from the platform-appropriate trust store. There seems to
>>>>> be a ruby method for it[2]
>>>> That would be great to test - it shouldn't be necessary, since Ruby
>>>> OpenSSL should do that by default, but if it fixes Ken's problem we
>>>> might have some other latent ... dunno. Oddity. Change in semantics
>>>> between Ruby versions. Something stupid like that.
>>>> Generally, though, you don't need to *do* anything to get Ruby OpenSSL
>>>> to validate commercial certificates.
>>>> --
>>>> Daniel Pittman
>>>> ⎋ Puppet Labs Developer – http://puppetlabs.com >>>> ♲ Made with 100 percent post-consumer electrons
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
>>>> To post to this group, send email to puppet-dev@googlegroups.com.
>>>> To unsubscribe from this group, send email to puppet-dev+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
