Trusting Self-Signed Certificates from the Chef Development Kit

If you're writing Chef cookbooks in a corporate environment, you may be developing against services on your internal network. As the services are not going to be exposed externally, the certificate used for HTTPS will be an intranet-only/self-signed cert, and therefore will require you to manually add it to your trust store.

You may think that "oh, but I've already trusted that cert in my Operating System / browser's trust store, so I don't need to make any other changes", but you would unfortunately be wrong. The ChefDK comes with its own trust store which needs to be updated with any certs you need.

UPDATE 2019-01-14: I used to recommend following a set of steps that would update the /opt/chefdk/embedded/ssl/certs/cacert.pem file in your ChefDK install. This was a bad decision, as it meant that you would need to re-update it each time you updated your ChefDK.

Instead, you should use knife ssl fetch for any certs you need:

$ knife ssl fetch
WARNING: No knife configuration file found
WARNING: Certificates from will be fetched and placed in your trusted_cert directory (/home/jamie/.chef/trusted_certs).

Knife has no means to verify these are the correct certificates. You should
verify the authenticity of these certificates after downloading.

Adding certificate for supermarket_example_com in /home/jamie/.chef/trusted_certs/supermarket_example_com.crt
Adding certificate for supermarket.example.com_1547487830 in /home/jamie/.chef/trusted_certs/supermarket.example.com_1547487830.crt

This places them within your home directory, and means that you can change your version of the ChefDK regularly, without risk of requiring pulling the new certs.

Note that this can be applied to any hosts inside your network that require communication over HTTPS, not just your Supermarket.

Note: If you are behind a corporate proxy, you will need to make sure that knife does not go via the proxy for these certs. This will mean you must set your no_proxy environment variable appropriately, otherwise you won't be able to successfully fetch the certificates.

Written by Jamie Tanna on , and last updated on .

Content for this article is shared under the terms of the Creative Commons Attribution Non Commercial Share Alike 4.0 International, and code is shared under the Apache License 2.0.

Related Posts

Other posts you may be interested in:

Interactions with this post

Interactions with this post

This post has had 0 WebMention interactions, as of Sun, 23 Jun 2019 22:31:19 +0100.

Have you written a response to this post? Let me know the URL: