[chef] Re: knife ssl check/fetch/check against a self-signed winrm ssl-transport host fails

[Daniel DeLeo < >]

On Tuesday, September 29, 2015 at 3:09 AM, Chris McClimans wrote:
> My goal is to securely connect to windows boxes from chef-provisioning 
> (aws),
> but I thought I'd try and connect via knife first.
>  
> I noticed that even after the knife ssl fetch, knife refuses to use
> the self-signed-cert.

Ugh, so at least part of the problem you’re seeing is that knife rescues all 
OpenSSL certificate errors, and assumes they happened when contacting the 
Chef Server over HTTPS. Using that assumption, it suggests that you run 
`knife ssl fetch`, which pulls down the certs and stores them so they’ll be 
added to the trust store for Chef’s HTTP stack. In your case, it appears that 
the issue is with the WinRM transport, which doesn’t know anything about the 
trusted_certs_dir, therefore the remediation steps that knife tells you to 
run are incorrect.

Unfortunately, we would need to make a lot of changes in order to fix this in 
the most correct way. Probably the best solution is for knife-windows to 
catch errors from winrm and wrap them in a different error class so they 
don’t hit knife’s top-level error handling code.
>  
> '''
> * trusted_certs_dir: "/home/hh/provisioning/.chef/trusted_certs"
> WARNING: There are invalid certificates in your trusted_certs_dir.
> OpenSSL will not use the following certificates when verifying SSL 
> connections:
>  
> /home/hh/provisioning/.chef/trusted_certs/ip-0A7146CD.crt: self signed
> certificate
> '''

This happens when a self-signed certificate doesn’t have the correct extended 
attributes to be able to trust itself. For HTTPS, this is a problem, but 
might not be for WinRM connections. However, as I said above, the ruby winrm 
library won’t use this cert anyway.
  

I’m not very familiar with bootstrapping windows instances with WinRM, so I 
can’t say what the recommended way to actually fix the root issue would be.

--  
Daniel DeLeo