In my case, I was doing basically the same thing, because the internal certificate path was different than the typical certificate path, so I had to add my internal certificates. In my case, adding the SSL_CERT_FILE didn't work. I needed to copy my certificates, which I had exported as *.cer and then made *.pem versions using
. ./openssl x509 -inform der -in C:\dev\apps\certificates\org_root.cer -out C:\dev\apps\certificates\org_root.pem
I found the openssl tool here:
Then I copied them to this location (which the location in the documentation above doesn't clarify very well) on the target machine:
I had to create the "trusted_certs" folder on my target machine where I wanted to run the chef client. After copying the certificates there, it began working and trusting the internal certificate chain without SSL errors (in my case self-signed certificate error).
Also, on the ChefDK machine if you're using kitchen or something like that, I had to take the contents of my internal certificates' *.pem files and copy the contents of the content to the tail of the "C:\opscode\chefdk\embedded\ssl\certs\cacert.pem" file or the cacert.pem file referenced by the SSL_CERT_FILE environment variable. In my case, I was copying an internal intermediate cert as well as a internal root cert and I believe they recommend that order also (ending with the root in the chain). This requirement on the ChefDK machine is due to the ChefDK communicating with a client machine using "remote_file" and the solution I'm providing appears to relate to this Chef bug, which may be fixed in newer versions of Chef.