We are perpetually playing whack-a-mole with /opt/{chef,chefdk} SSL cert
bundles.
We put our CA chain certs in /etc/chef/trusted_certs. Great, chef-client
can talk to the server.
Then there’s /opt/*/embedded/ssl/certs/cacert.pem
We append our CA chain certs there. That’s pretty “cheap” due to the
consistent path name and can be targeted easily via our custom certs
cookbook.
Great. Now chef_gem works when talking to internet https endpoints
through our company’s mandated SSL inspection device.
Now ChefDK 0.8.1 has
/opt/chefdk/embedded/ruby/gems/ruby/gems/ruby/gems/2.1.0/chef/bundles/apps/2.1.0/chef/ruby/stuff/noodles/rake/httpclient-2.something
which has its own cacert.p7s file and a completely expensive cost to
solving cleanly (read: not embedded that huge fragile path in some
recipe). That is, we’re reduced to running ‘find /opt/chefdk -name
cacert.p7s’ + other crap in an execute resource.
We sure would like to hear peoples’ ideas, cause this is madness.
1 Like
Just a guess (unverified), but for bundler I had to use the environment
variable SSL_CERT_FILE and point it to embedded/ssl/certs for it to work
under windows. Maybe httpclient could take this env variable too ?
Le 2015-10-01 23:14, Jeff Blaine a écrit :
We are perpetually playing whack-a-mole with /opt/{chef,chefdk} SSL cert
bundles.
We put our CA chain certs in /etc/chef/trusted_certs. Great, chef-client
can talk to the server.
Then there's /opt/*/embedded/ssl/certs/cacert.pem
We append our CA chain certs there. That's pretty "cheap" due to the
consistent path name and can be targeted easily via our custom certs
cookbook.
Great. Now chef_gem works when talking to internet https endpoints
through our company's mandated SSL inspection device.
Now ChefDK 0.8.1 has
/opt/chefdk/embedded/ruby/gems/ruby/gems/ruby/gems/2.1.0/chef/bundles/apps/2.1.0/chef/ruby/stuff/noodles/rake/httpclient-2.something
which has its own cacert.p7s file and a completely expensive cost to
solving cleanly (read: not embedded that huge fragile path in some
recipe). That is, we're reduced to running 'find /opt/chefdk -name
cacert.p7s' + other crap in an execute resource.
We sure would like to hear peoples' ideas, cause this is madness.
On Fri, Oct 02, 2015 at 10:57:15AM +0200, Tensibai wrote:
Just a guess (unverified), but for bundler I had to use the environment
variable SSL_CERT_FILE and point it to embedded/ssl/certs for it to work
under windows. Maybe httpclient could take this env variable too ?
It would be much better if Chef used one cert store, not a number of them.
It would be perfect if Chef just used system CA store.
--
Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzichubg@chrome.pl -- Mitchell Blank on LKML
1 Like
Le 2015-10-02 11:35, Tomasz Torcz a écrit :
On Fri, Oct 02, 2015 at 10:57:15AM +0200, Tensibai wrote:
Just a guess (unverified), but for bundler I had to use the environment
variable SSL_CERT_FILE and point it to embedded/ssl/certs for it to work
under windows. Maybe httpclient could take this env variable too ?
It would be much better if Chef used one cert store, not a number of them.
It would be perfect if Chef just used system CA store.
If you're willing to make something to parse Windows system cert store
to something like a .pem cert store on the fly, you're welcome to
contribute it 
(But it's really harder than it seems)
On Friday, October 2, 2015 at 3:00 AM, Tensibai wrote:
Le 2015-10-02 11:35, Tomasz Torcz a écrit :
On Fri, Oct 02, 2015 at 10:57:15AM +0200, Tensibai wrote:
Just a guess (unverified), but for bundler I had to use the environment
variable SSL_CERT_FILE and point it to embedded/ssl/certs for it to work
under windows. Maybe httpclient could take this env variable too ?
It would be much better if Chef used one cert store, not a number of them.
It would be perfect if Chef just used system CA store.
If you're willing to make something to parse Windows system cert store to something like a .pem cert store on the fly, you're welcome to contribute it (But it's really harder than it seems)
Someone actually contributed code for this to OpenSSL, but it was never accepted, and I’m not sure why. Similarly, Apple never contributed their patch for OpenSSL back upstream (AFAIK) and are moving on from OpenSSL in general, so they are not maintaining their patch. Short of patching OpenSSL, the only other way to do this is to extract the contents of the system store to the cacert.pem file and format. But in order to get updates, this would need to be able to run regularly.
--
Daniel DeLeo
I would definitely be in favor of a feature to allow users to use the
Windows cert store. This would create some workflow differences between
Windows and non-Windows systems for instance, but overall it would make life
much simpler in multiple areas.
In theory, there's no reason we need to use OpenSSL on Windows -- we could
simply use the crypt32* APIs. This would give us Windows cert store
integration, among many other features.
-Adam
-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Friday, October 2, 2015 8:44 AM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: Re: Re: Chef * + bundled SSL cert bundles are not
delightful
On Friday, October 2, 2015 at 3:00 AM, Tensibai wrote:
Le 2015-10-02 11:35, Tomasz Torcz a écrit :
On Fri, Oct 02, 2015 at 10:57:15AM +0200, Tensibai wrote:
Just a guess (unverified), but for bundler I had to use the
environment variable SSL_CERT_FILE and point it to
embedded/ssl/certs for it to work under windows. Maybe httpclient
could take this env variable too ?
It would be much better if Chef used one cert store, not a number of
them.
It would be perfect if Chef just used system CA store.
If you're willing to make something to parse Windows system cert store
to something like a .pem cert store on the fly, you're welcome to
contribute it (But it's really harder than it seems)
Someone actually contributed code for this to OpenSSL, but it was never
accepted, and I’m not sure why. Similarly, Apple never contributed their
patch for OpenSSL back upstream (AFAIK) and are moving on from OpenSSL in
general, so they are not maintaining their patch. Short of patching OpenSSL,
the only other way to do this is to extract the contents of the system store
to the cacert.pem file and format. But in order to get updates, this would
need to be able to run regularly.
--
Daniel DeLeo
The system CA store is, more often, horribly out of date.
On 10/02/2015 02:35 AM, Tomasz Torcz wrote:
On Fri, Oct 02, 2015 at 10:57:15AM +0200, Tensibai wrote:
Just a guess (unverified), but for bundler I had to use the environment
variable SSL_CERT_FILE and point it to embedded/ssl/certs for it to work
under windows. Maybe httpclient could take this env variable too ?
It would be much better if Chef used one cert store, not a number of them.
It would be perfect if Chef just used system CA store.
On Fri, Oct 02, 2015 at 09:04:01AM -0700, Lamont Granquist wrote:
The system CA store is, more often, horribly out of date.
I find it fairly up-to-date on all reasonable distributions. Also
this is THE place to put custom CA certs.
Moreover, updating one out of date repository is many times easier
than updating THREE disparate repositories in different format.
--
Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzichubg@chrome.pl -- Mitchell Blank on LKML
2 Likes