We believe that the best way to build software is to do it in close collaboration with the people who use it. We invite you to submit your ideas using the form below. Please be sure to include the problem for which you are solving and the benefits of implementing the idea.
We do our best to implement as many Ideas as we can. Our Product team will evaluate all submitted ideas in a timely manner and will disposition each into one of the following categories: will integrate into the product roadmap, further research is needed, unlikely to implement.
Thanks for collaborating with us!
In the deprecated windows cookbook, there is a resource called windows_certificate_binding. In v4.3.2 of that cookbook, there was a bug in the Get-ChildItem selection criteria that would attempt to bind to a non-SSL certificate:
Buggy code:
gci cert:\localmachine\MY | where { $_.subject -like '*{hostname}*' } | select -first 1 -expandproperty Thumbprint
When consulting with Chef support, a recommendation was to migrate to the v7.0.2 prior to its deprecation announcement. However, since the windows cookbook is now being deprecated, we need to have this functionality implemented in the core Chef client instead to fix this bug.
The "new" cookbook on the Supermarket does not address the original bug that selects certificates without confirming that they have the 'Server Authentication' OID in the EKU.
We've created a new cookbook on the Supermarket with the existing code from the Windows cookbook: https://supermarket.chef.io/cookbooks/windows_certificate_binding. We'll do minimal refactoring of codebase to bring it up to 2021 standards and then move that into Chef Infra Client where we can take customer feedback and further refine it.
Here are potential bug fixes to the underlying code:
gci cert:\localmachine\MY -SSLServerAuthentication | where { $_.subject -like '*{hostname]*' } | select -first 1 -expandproperty Thumbprint
Or this (in case the -SSLServerAuthentication parameter is not available for Get-ChildItem):
gci cert:\localmachine\MY | where { $_.subject -like '*{hostname}*' -and $_.EnhancedKeyUsageList -like '*Server Authentication*' } | select -first 1 -expandproperty Thumbprint
This will eliminate any certificates that do not have the proper OID in the EKU to provide SSL binding in the first place.
We could really use this bugfix. It looks like the bug reported in ticket #26109 (windows_certificate_binding resource does not bind properly when multiple certificates are available) still exists in the latest version of the (now deprecated) "windows" cookbook here: https://github.com/chef-boneyard/windows/blob/master/resources/certificate_binding.rb#L118